BMV2 backend generates no errors for hash input expressions it can't handle

[kucejan]

According JSON input format BMV2 does not accept expressions as an input for hash calculations. However, no error is generated if you use an expression it can't handle; the result is just silent failure. BMV2 does not output any error with the generated JSON, but the output value of the hash is always zero regardless the input.

An example of a code:

hash(meta.hashvalue, HashAlgorithm.crc32, (bit<32>) 0, { hdr.ipv4.srcAddr & 0xFF000000 }, (bit<32>) TABSIZE);

Relevant fragment of the generated JSON:

  "calculations" : [
    {
      "name" : "calc",
      "id" : 0,
      "algo" : "crc32",
      "input" : [
        {
          "type" : "expression",
          "value" : {
            "op" : "&",
            "left" : {
              "type" : "field",
              "value" : ["ipv4", "srcAddr"]
            },
            "right" : {
              "type" : "hexstr",
              "value" : "0xff000000"
            }
          }
        }
      ]
    }
  ],

[mihaibudiu]

If @antoninbas can confirm this diagnosis it should be relatively easy to fix this in the compiler.
The question is: what other built-in externs have similar restrictions?

[antoninbas]

I can confirm this. I updated the bmv2 JSON parser to throw an error in this case (p4lang/behavioral-model#322).
The expressions need to be evaluated and the results written to temporaries.
Usually this restriction applies whenever a built-in extern has to consume a field list / tuple / list expression; generate_digest comes to mind, but support for that is a little hacky IIRC.

[kucejan]

I can confirm the problem with digest() too.

digest<digest_t>(0, { meta.val + 5 });
-------
bit<32> temp = meta.val + 5;
digest<digest_t>(0, { temp });

In both cases expression type element is generated, but in the case of digest, running generated JSON in BMV2 ends up with SIGABRT due to assertion.

lt-simple_switch: P4Objects.cpp:1553: void bm::P4Objects::init_learn_lists(const Json::Value&): Assertion `type == "field"' failed.

But during my experiments, I have found another weird behaviour of digest(). If I use temporary metadata field and modify it just after the digest() call again, a digest with the new value of the field is sent. For example value meta.val + 10 is sent in the digest in this code:

meta.digestval = meta.val + 5;
digest<digest_t>(0, { meta.digestval });
meta.digestval = meta.digestval + 5;

[mihaibudiu]

I think that the P4-14 spec was never clear about this fact, but actually the digest is given a reference to a field list, and the digest always executes at the end of the pipeline.

In P4-16 there are no references, so this kind of behavior is impossible to express in the language. By using a fresh temporary the compiler can implement the "eager" semantics.

We have a problem with regards to P4-14 programs; when translating them to P4-16 we can implement either semantics (delayed evaluation or immediate evaluation) by playing with temporaries.

There may be additional difficulties related to the control-plane API of the digest primitive; this is also not clearly specified.

[mihaibudiu]

The PR above fixes the "complex expression" problem, but it does not fix the weird semantics for digest.
So this issue should not yet be closed.

Unfortunately our testing framework does not support digest, so we can't write a test for this issue.