adds table entries support #397

cc10512 · 2017-03-27T01:48:44Z

Adds two IR nodes (IR::Entry and IR::EntriesList) as table properties

Adds the serialization of predefined entries to JSON (requires JSON
v2.7 or later) and a series of tests for table entries.

As part of the serialization, the match key type detection was
refactored to be common for generating table match keys and
determining the type of keysets in entries.

The typechecker needed convincing to accept action 'calls' in the
entry definition.
Action call parameters were being removed by the removeParameters
pass, which should not happen -- action data needs to be serialized
into the bmv2 json.

When disabling for IR::EntriesList, the type inference complains
... not sure why. So there are a couple of instances in the type
inference visitors where we check whether or not we are in an
EntriesList context and elide the type parameter checking. There
should be a cleaner way.

CONST ENTRIES grammar rule conflicts with CONST IDENTIFIER rule. For
now the only way this works is removing the CONST. We need to bring it
back.

mihaibudiu

The biggest bug is using ActionListElement in an Entry; ActionListElement is only meant for the list of action names that show up in the "actions" list. You should use an Expression. Then some of the special cases you wrote will go away.

mihaibudiu · 2017-03-27T03:45:25Z

backends/bmv2/jsonconverter.cpp

+*/
+void JsonConverter::convertTableEntries(const IR::P4Table *table,
+                                        Util::JsonObject *jsonTable)
+{


I think that Chris likes the brace on the previous line. This applies everywhere.

the cpplint commit addresses all the styling issues.

mihaibudiu · 2017-03-27T15:37:17Z

backends/bmv2/jsonconverter.cpp

+            auto matchType = getKeyMatchType(tableKey);
+            key->emplace("match_type", matchType);
+            if (matchType == "valid") {
+                if(k->is<IR::BoolLiteral>())


You need a space after if. This happens many times; I won't flag all of them.

mihaibudiu · 2017-03-27T15:40:38Z

backends/bmv2/jsonconverter.cpp

+                    key->emplace("key", stringRepr(k->to<IR::Constant>()->value, ROUNDUP(keyWidth, 8)));
+                    unsigned long mask = (1ULL << keyWidth)-1;
+                    key->emplace("mask", stringRepr(mask, ROUNDUP(keyWidth, 8)));
+                } else if (k->is<IR::DefaultExpression>()) {


For this one to work correctly you will need to have a pass that converts default expressions to lists, similar to SimplifySelectList.

I don't understand why. These are the keyset elements that get set as default, not the whole list as default.

Look at the following example ../testdata/p4_16_samples/select_struct.p4 and check the output from the compiler.

mihaibudiu · 2017-03-27T15:43:24Z

backends/bmv2/jsonconverter.cpp

+                    key->emplace("mask", stringRepr(k->to<IR::Mask>()->right->to<IR::Constant>()->value, ROUNDUP(keyWidth, 8)));
+                } else if (k->is<IR::Constant>()) {
+                    key->emplace("key", stringRepr(k->to<IR::Constant>()->value, ROUNDUP(keyWidth, 8)));
+                    unsigned long mask = (1ULL << keyWidth)-1;


You should use mpz; keyWidth can be bigger than 64.

even though width_bits() is defined as:

// This is well-defined only for types with fixed width virtual int width_bits() const { return 0; }

in base.def:21?

Consider the case of an ipv6 key field.

mihaibudiu · 2017-03-27T15:44:22Z

backends/bmv2/jsonconverter.cpp

+    if (entriesList == nullptr) return;
+
+    auto entries = mkArrayField(jsonTable, "entries");
+    int entryPriority = 1; // priority is defined by index position


This comment is misleading; it should say "default priority"; you are overwriting it below from an annotation.

mihaibudiu · 2017-03-27T16:29:41Z

ir/ir.def

+/// Pre-defined entry in a table
+class Entry : IAnnotated {
+    Annotations         annotations;  /// annotations are optional (supported annotations: @priority(value))
+    ListExpression      keys;         /// must be a tuple expression


default should be a legal key; I suggest having this be an Expression, exactly like a SelectCase.

see the above comment on how I'm handling default.

mihaibudiu · 2017-03-27T16:32:24Z

ir/ir.def

+class Entry : IAnnotated {
+    Annotations         annotations;  /// annotations are optional (supported annotations: @priority(value))
+    ListExpression      keys;         /// must be a tuple expression
+    ActionListElement   action;       /// action must be defined in action list


This should also be an expression; in general it will be a MethodCallExpression.
Don't use ActionListElement, there control-plane arguments are not bound, so the type-checking is different.

will this solve my other type checker issues?

mihaibudiu · 2017-03-27T16:33:26Z

midend/removeParameters.cpp

@@ -76,6 +76,12 @@ void FindActionParameters::postorder(const IR::MethodCallExpression* expression)
    }
 }

+const IR::Node* DoRemoveActionParameters::preorder(IR::EntriesList *list)


You MUST remove action parameters - this takes care of the data-plane bound parameters.
This function should be removed; it may work correctly if you make the change above.

mihaibudiu · 2017-03-27T16:35:19Z

testdata/p4_16_samples/table-entries-exact-bmv2.p4

+      entries = {
+        0x01 : a_with_control_params(1);
+        0x02 : a_with_control_params(2);
+#ifdef ENABLE_NEGATIVE_TESTS


I think you should make two tests out of this one.

yes, I'll work on handling the negative testing separately.

mihaibudiu · 2017-03-27T16:36:34Z

testdata/p4_16_samples/table-entries-exact-bmv2.p4

@@ -0,0 +1,81 @@
+/*


You should also write some tests where you use "default" to match a tuple, and also where actions have data-plane arguments.

there are default entry tests in almost all the test cases. Again, the way I expect defaults for tuples is (_, _).

This is not symmetric with the select, and it is also less consistent.

antoninbas

Could you set the version number to 2.7 in the generated JSON?

mihaibudiu · 2017-03-27T23:01:52Z

The typechecker will probably need an extension similar to SelectExpression and matchCase to typecheck the entries.

cc10512 · 2017-03-28T04:57:59Z

@mbudiu-vmw I replaced the ActionListElement with a MethodCallExpression and was able to successfully remove two of the hacks in typeChecker (the ugly ones), as well as having the default behavior for removeParameters.

There is only the remaining issue with the typeChecker thinking I mutated the program.

build> bmv2/testdata/p4_16_samples/table-entries-exact-ternary-bmv2.p4.test 
Error compiling
libc++abi.dylib: terminating with uncaught exception of type Util::CompilerBug: COMPILER BUG: ../frontends/p4/typeChecking/typeChecker.cpp:120
<P4Program>(8893): typechecker mutated node <P4Program>(7991)


*** Test failed

cc10512 · 2017-03-31T23:30:02Z

@mbudiu-vmw: I revised the code according to your guidance. Still need to add the negative tests (I have them) but need to figure out a way of handling multiple types of errors in a single test. I will open a separate issue for that so that it doesn't slip.

There may be a few other things that can be optimized, however, I would like to merge this PR so that folks developing the tutorial materials for the developer day (in particular @robertsoule and @vgurevich) can use this feature.

mihaibudiu · 2017-03-31T23:31:36Z

For negative tests it's easiest to write 1 file/test.
There are always things that can be optimized.
If the PR is ready for review I will re-read it.

mihaibudiu · 2017-04-02T00:53:55Z

backends/bmv2/jsonconverter.cpp

+            auto match_type = getKeyMatchType(ke);
+            if (match_type == v1model.selectorMatchType.name)
+                    continue;
+            // Decreasing order of precedence:


These rules should really be part of the v1model spec - which does not exist.
They were reverse-engineered from the p4-14 compiler.
Maybe this information should be in this comment.

Updated comment. It is actually what BMv2 expects (which might be the same as v1model spec).

mihaibudiu · 2017-04-02T00:55:39Z

frontends/p4/p4-parse.ypp

@@ -776,6 +783,13 @@ tableProperty
                                           auto id = IR::ID(@1, "actions");
                                           $$ = new IR::Property(
                                               @1 + @5, id, IR::Annotations::empty, v, false); }
+    /* \todo: force CONST entries? conflicts with next rule */


This should be fixed too.
Would it work to have two rules:

optAnnotations ENTRIES ... optAnnotations const ENTRIES ...

Maybe @ChrisDodd can help suggest a way to remove this ambiguity. It is important to have the const.

i'll ask Chris for help

mihaibudiu · 2017-04-02T00:56:56Z

frontends/p4/p4-parse.ypp

@@ -813,6 +827,34 @@ actionRef
                                           $$ = new IR::ActionListElement(@2, $1, mce); }
    ;

+entry
+    : optAnnotations keysetExpression ':' actionInvocation


I suggest replacing this with

: optAnnotations keysetExpression : initializer ';'

The code becomes much simpler.

Unfortunately, initializer is defined just an expression. I really think this should point to an invocation expression, i.e., we should at least have an action reference with (). As opposed to default_action which can also take actions without (). AFAIK, at least in P4_14, we distinguish between the two types (one is const and one is not). I think this is resolved in P4_16 by using the const keyword for default_action, but we still do not require the () for an action without parameters. I would prefer to have the () enforced in the grammar.

Actions cannot be generic, so you don't need the actionInvocation with <>.

bison gives bad error messages; we can give a much better error message in the type-checker. Even if the grammar accepts without (), we can enforce this later.

whatever this syntax is for actionInvocation, it should accept the same kinds of expressions as the default_action does. They are both accepting actions with all parameters bound. There is no reason that one of them accepts without () and the other one doesn't.

By using initializer we can remove two productions from the grammar. This is not the right metric to optimize, but it's still useful to have a small grammar.

Please note that this is not really an invocation, so the name of the production is unsuitable. It is just binding the arguments; the invocation happens at runtime.

@mbudiu-vmw: there is no definition for default_action, it falls on the generic rule

| optAnnotations optCONST IDENTIFIER '=' initializer ';'

and initializer is in fact an expression.
In fact reviewing the grammar to look for an action invocation, the only pertinent rule I found is assignmentOrMethodCallStatement, and I borrowed the rules for actionInvocation from there. I think that a more clean implementation should split that rule into the assignment and actionInvocation and in that case there are no additional rules, and the intent is much more obvious.

mihaibudiu · 2017-04-02T00:57:51Z

frontends/p4/toP4/toP4.cpp

@@ -1176,6 +1176,36 @@ bool ToP4::preorder(const IR::TableProperties* t) {
    return false;
 }

+bool ToP4::preorder(const IR::EntriesList *l) {
+    dump(1);
+    // if (l->isConstant)


If the grammar can be fixed this should be added.

mihaibudiu · 2017-04-02T01:00:09Z

frontends/p4/typeChecking/typeChecker.cpp

+    LOG2("Setting key type to " << dbp(keyTuple));
+    setType(key, keyTuple);
+    // installing also for the original because we cannot tell which one will survive in the ir
+    // \TODO: figure out the rules of survivorship


This comment applies to almost all the methods in all visitors. So it's not very useful here.
This is a problem with the current visitor design.

good point. The larger issue is to understand both why there are additional copies and their lifetime. @cole-barefoot, @jnfoster, and I looked over the visitor code on Fri and we have a number of questions that we'll discuss with @ChrisDodd on Mon.

The problem stems from the fact that the visitor always passes you a clone of the node, both in preorder and postorder. But you have no idea whether this copy differs from the original because you are changing it or because someone else changed one of its children.

One can design a visitor were there are never any automatic clones. I proposed to add one such visitor implementation, where all mutations must be made only by the user. This would be easier to debug, but would require users writing more code in some circumstances. Today all transforms use at least O(n) space because of this feature, even if they change no nodes!

Alternatively, we could endow the visitor with an upcall when a node is substituted; this could enable us to incrementally update some data structures such as typemaps.

Actually O(log n) space (bounded by the depth of the tree, not the size of the tree). I'm not sure how to design a visitor pattern that does no automatic clones, since you need to clone any node that has any children changed (recursively through grandchildren) even if you don't otherwise want to change the node. When I tried it, you end up needing to manually define preorder and postorder functions for almost every possible IR type, which seems impractical.

Note that if you really want to know whether this node has changed in a postorder function, and only insert into the typemap in that case, you can use:

if (*key != *getOriginal()) setType(key, keyTuple);

This doesn't work in a preorder function as it only tells you if the ndoe has changed yet, and not if it might be changed in the future from traversing its children or in the postorder function.

Maybe we should change the setType helper function to work this way.
Or add another helper.

mihaibudiu · 2017-04-02T01:09:11Z

frontends/p4/typeChecking/typeChecker.cpp

@@ -1647,6 +1760,7 @@ const IR::Node* TypeInference::typeSet(const IR::Operation_Binary* expression) {
        // set after unification
        auto r = expression->right->clone();
        auto e = expression->clone();
+        if (isCompileTimeConstant(expression->right)) setCompileTimeConstant(r);


It's easier to debug if you have only one statement per line.

mihaibudiu · 2017-04-02T01:10:06Z

frontends/p4/validateParsedProgram.cpp

    if (!isv1 && da == nullptr)
        ::warning("Table %1% does not have an `%2%' property",
                t->name, IR::TableProperties::defaultActionPropertyName);
+
+    auto entriesList = t->getEntries();
+    if (entriesList != nullptr) {  // list of entries is optional


I think that this check is completely subsumed by the type checker.

Right. Actually this is a check that I forgot to remove and did not yet add to the type checker.

mihaibudiu · 2017-04-02T01:10:25Z

frontends/p4/validateParsedProgram.cpp

+            auto keyset = e->getKeys();
+            if (keyset == nullptr || !keyset->is<IR::ListExpression>())
+                ::error("%1%: key expression must be tuple", keyset);
+            else if (keyset->to<IR::ListExpression>()->components->size() <


This is also wrong if you allow DefaultExpression.

mihaibudiu · 2017-04-02T01:11:40Z

testdata/p4_16_samples/table-entries-exact-bmv2.p4

@@ -0,0 +1,81 @@
+/*


This is not symmetric with the select, and it is also less consistent.

mihaibudiu · 2017-04-02T01:12:05Z

testdata/p4_16_samples/table-entries-exact-bmv2.p4

+    action a() { standard_meta.egress_spec = 0; }
+    action a_with_control_params(bit<9> x) { standard_meta.egress_spec = x; }
+
+    table t_exact {


It would be nice to use a standard indentation for P4 programs too.

mihaibudiu · 2017-04-03T16:03:49Z

frontends/p4/p4-parse.ypp

+actionInvocation
+    : lvalue '(' argumentList ')' ';'  { $$ = new IR::MethodCallExpression(@1 + @4, $1,
+                                                               new IR::Vector<IR::Type>(), $3); }
+    | lvalue '<' typeArgumentList '>' '(' argumentList ')' ';'


This rule should be removed; actions cannot have type arguments.

mihaibudiu · 2017-04-03T16:04:26Z

frontends/p4/p4-parse.ypp

+                                         }
+    ;
+
+actionInvocation


actionBinding or actionConstruction is a more suitable name. The action is not being invoked.

mihaibudiu · 2017-04-03T16:05:39Z

frontends/p4/typeChecking/typeChecker.cpp

+    }
+
+    // the key must have been typechecked already.
+    if (!typeMap->contains(key)) {


This is too early: in preorder the type of the key has not been computed yet.
You need a negative test for this case too - the entries coming before the key.

mihaibudiu · 2017-04-03T16:06:20Z

testdata/p4_16_errors/table-entries-decl-order.p4

+
+    table t_ternary {
+
+#if ENABLE_NEGATIVE_TESTS


Is this ever used?
If not it should be removed.

it is defined in line 20 and used here.

mihaibudiu · 2017-04-03T16:06:57Z

testdata/p4_16_errors/table-entries-exact.p4

+            0x02 : a_with_control_params(2);
+#ifdef ENABLE_NEGATIVE_TESTS
+            // test default entries
+            _ : a_with_control_params(3);


Why is this a negative test? This is legal.

what is the default for an exact key? In BMv2, I support default only for ternary, lpm, and range.

This is a tricky one; I am not sure it should be a negative test.
I can write a compiler pass which would cause this program to work. You could claim that it reflects a shortcoming in the implementation.
A negative test should be an illegal program, which will never be accepted.
This program is somewhere in a gray area.

For any program (and backend for that matter) the keyset has to resolve to an actual value that can be installed as a match. We can do that for some other types of matches but not for exact matches. It is in a gray area because you're thinking about these keyset expressions as select expressions. I argue that they are not.

Here is an example:

bit x; table t { key = { x: exact; } ... const entries = { default: a(); } }

This can be easily translated to:

const entries = { 1w0: a(); 1w0: a(); }

These two programs are semantically equivalent.

Also, note that nothing in the spec says that the compiler cannot change the key type if necessary; perhaps the compiler can convert a table with exact keys into a table with ternary keys. We should not rule out these possibilities.

I do not agree that these programs are semantically equivalent unless you explicitly say that 0 is a default value in an exact match table (which I don't recall being in the spec). A key value of 0 for either exact or ternary is different from a 0 mask for a ternary key (which is what the default for a ternary key is -- matching any). So even if you have a semantically preserving transformation from exact to ternary keys, these two programs are not equivalent.

@mbudiu-vmw you've given me a whole lot of good feedback on this PR and I am grateful for your careful reviews. But on this one, we should just agree to disagree and move on. Please.

Sorry, the example should have been 1w0: a(); 1w1: a().
Anyway, this is not very important - it is just a test case.

mihaibudiu · 2017-04-03T16:08:06Z

testdata/p4_16_errors/table-entries-range.p4

+            _    : a_with_control_params(23);
+#ifdef ENABLE_NEGATIVE_TESTS
+            // negative tests:
+            (0x18, 0xF) : a_with_control_params(24); // not a range


I don't think we want to declare this being a negative test.
A mask may be convertible to a set of ranges.

i don't think we should support such implicit conversions.

It is not up to the front-end to decide what conversions are supported.
The back-end should reject such programs, not the type-checker.

mihaibudiu · 2017-04-03T16:08:43Z

testdata/p4_16_errors/table-entries-exact-ternary.p4

@@ -0,0 +1,86 @@
+/*


If you name all these files ending with -bmv2, then the p4c-bm2-ss compiler will be used, and the output json will be validated by bmv2.

should they be checked by bmv2 or just p4test?

p4test runs all of them.
p4c-bm2-ss runs all the ones that end with bmv2.p4. And the output json is validated by the simulator. So you want to use it, because otherwise the json generation code is not exercised.

mihaibudiu · 2017-04-03T16:09:19Z

testdata/p4_16_errors_outputs/table-entries-decl-order.p4-stderr

+../testdata/p4_16_errors/table-entries-decl-order.p4(53): error: Table initializer entries must occur after key definitions (table t_ternary)
+    table t_ternary {
+          ^^^^^^^^^
+../testdata/p4_16_errors/table-entries-decl-order.p4(66): error: Could not find type of Key


Do you want the same error message 3 times?

No, i don't want repeated messages, but these are different entries, and each of them gets checked. Are you suggesting to prune the rest of the children if an error is encountered? I thought we were leaning toward reporting as many errors as possible.

They may be different entries, but they all generate the same error message.
We want to show as many informative errors as possible, but the second one does not bring anything new.

mihaibudiu · 2017-04-03T16:10:35Z

testdata/p4_16_errors_outputs/table-entries-exact-ternary.p4-stderr

@@ -0,0 +1,4 @@
+../testdata/p4_16_errors/table-entries-exact-ternary.p4(74):syntax error, unexpected ')', expecting ','


This actually looks like a legitimate key expression. Why is this an error?

needs a pair to match the key type of the table

This should not be a syntax error, perhaps a type error.

mihaibudiu · 2017-04-03T16:13:42Z

testdata/p4_16_errors/table-entries-exact-ternary.p4

+            (0x02, 0x1181           ) : a_with_control_params(2);
+            (0x03, 0x1111 &&& 0xF000) : a_with_control_params(3);
+            // test default entries
+            (0x04, _                ) : a_with_control_params(4);


Can you also please add a case

default : a_with_control_params(6);

what is the default for an exact key in bmv2?

The actual implementation for default is up to the back-end.
But the front-end should typecheck this program.

mihaibudiu · 2017-04-03T16:22:49Z

You do allocate O(n), but you may reclaim all of it if there are no changes.

mihaibudiu · 2017-04-04T16:19:55Z

frontends/p4/p4-parse.ypp

                                                               new IR::Vector<IR::Type>(), $3); }
-    | lvalue '<' typeArgumentList '>' '(' argumentList ')' ';'
+    | lvalue '<' typeArgumentList '>' '(' argumentList ')'


This is useless, since actions cannot have type arguments.

mihaibudiu · 2017-04-04T16:21:12Z

frontends/p4/p4-parse.ypp

@@ -828,26 +828,26 @@ actionRef
    ;

 entry
-    : optAnnotations keysetExpression ':' actionInvocation
+    : keysetExpression ':' actionBinding optAnnotations ';'


This is somewhat unfortunate, but I don't have a counter-proposal.

mihaibudiu · 2017-04-04T16:22:13Z

frontends/p4/validateParsedProgram.cpp

+void ValidateParsedProgram::postorder(const IR::EntriesList* l) {
+    auto table = findContext<IR::P4Table>();
+    if (table == nullptr)
+        ::error("%1%: table initialziers must belong to a table", l);


typo in error message

Adds two IR nodes (IR::Entry and IR::EntriesList) as table properties Adds the serialization of predefined entries to JSON (requires JSON v2.7 or later) and a series of tests for table entries. As part of the serialization, the match key type detection was refactored to be common for generating table match keys and determining the type of keysets in entries. The typechecker needed convincing to accept action 'calls' in the entry definition. Action call parameters were being removed by the removeParameters pass, which should not happen -- action data needs to be serialized into the bmv2 json. When disabling for IR::EntriesList, the type inference complains ... not sure why. So there are a couple of instances in the type inference visitors where we check whether or not we are in an EntriesList context and elide the type parameter checking. There should be a cleaner way. CONST ENTRIES grammar rule conflicts with CONST IDENTIFIER rule. For now the only way this works is removing the CONST. We need to bring it back.

* proper type checking for table initializers that removes the hacky implementation of shortcuts Refactored the type checking for table initializers in checking the entire list for matching table structures, and then entries for checking legality of keys, key types, constants, and actions. Uses (and )typeSet to set expressions to compile time constants even when creating new IR::Constant expressions for left and right operands, as well as set the set itself to be a compile time constant if its members are both constants. * proper methods for annotation handling and updates min JSON version * use MethodCallExpression instead of ActionListElement for actions in table entry initializer * use mpz_class for mask to represent masks larger than 64 bits * adds sample outputs for p4test

* Moves EntriesList checking to pre-order * Moves checks from validateParsedProgram to type checker * Fixes returns on errors

…ry rule Changes the grammar to rename actionInvocation to actionBiding and move annotations for entries at the end of the statement, such that we avoid a shift/reduce conflict in the grammar. Also tried splitting assignmentOrMethodCallStatement into assignmentStatement and methodCallStatement that is just transforming an actionBinding (MethodCallExpression) into a Statement, but that creates more issues in the grammar. Fiddled with the tests to move annotations at the end ... so happened that I had to pick the test with annotations to test all error conditions :(

cc10512 requested review from antoninbas, ChrisDodd and mihaibudiu March 27, 2017 01:48

ChrisDodd approved these changes Mar 27, 2017

View reviewed changes

mihaibudiu requested changes Mar 27, 2017

View reviewed changes

antoninbas approved these changes Mar 27, 2017

View reviewed changes

cc10512 force-pushed the cc/table-entries branch from 45b033c to d8782ca Compare March 28, 2017 04:54

cc10512 force-pushed the cc/table-entries branch from eecc82f to 8f13347 Compare March 31, 2017 23:25

mihaibudiu requested changes Apr 2, 2017

View reviewed changes

cc10512 force-pushed the cc/table-entries branch from ae3d515 to d513bfb Compare April 2, 2017 19:51

mihaibudiu requested changes Apr 3, 2017

View reviewed changes

cc10512 force-pushed the cc/table-entries branch 2 times, most recently from 94ea36e to d26dfb7 Compare April 4, 2017 06:41

mihaibudiu requested changes Apr 4, 2017

View reviewed changes

mihaibudiu approved these changes Apr 4, 2017

View reviewed changes

Calin Cascaval and others added 9 commits April 4, 2017 17:38

fix printing toP4 and enforce keysets to be ListExpressions

05662ed

cpplint

033e028

fixes indentation

d394494

addresses reviewer comments

b92aa8d

* Moves EntriesList checking to pre-order * Moves checks from validateParsedProgram to type checker * Fixes returns on errors

negative tests

ef44740

clean up CONST qual and attibs on table properties

7e4768f

add validation for const entries

4704637

Calin Cascaval added 2 commits April 4, 2017 17:39

remove .bak file

63442c0

cc10512 force-pushed the cc/table-entries branch from d26dfb7 to 63442c0 Compare April 5, 2017 00:40

cpplint

1402e22

cc10512 merged commit 9ff9677 into p4lang:master Apr 5, 2017

This was referenced Apr 5, 2017

Handling of tables with multiple "lpm" match type fields #60

Closed

feature: p4: initializing tables from p4 program #102

Closed

fefer mentioned this pull request Aug 7, 2018

"make" get's 100% without error, but "make check" fails #1433

Closed

		@@ -0,0 +1,4 @@
		../testdata/p4_16_errors/table-entries-exact-ternary.p4(74):syntax error, unexpected ')', expecting ','

adds table entries support #397

adds table entries support #397

Conversation

cc10512 commented Mar 27, 2017

mihaibudiu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

antoninbas left a comment

Choose a reason for hiding this comment

mihaibudiu commented Mar 27, 2017

cc10512 commented Mar 28, 2017

cc10512 commented Mar 31, 2017

mihaibudiu commented Mar 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mihaibudiu Apr 4, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mihaibudiu Apr 4, 2017 •

edited

Loading