Add statement splitter utility

[vlstill]

Add functionality for splitting statements. Split given statement so that on all control-flow paths all the statements up to the first one matching predicate are in a before statement, while the rest (starting from the matching statemet) is in an after statement.

The visiting order is a bit tricky, but it should work for any code without loops and without non-spec branching constructs. Not currently used in P4C, but I think this is worth having as it can be useful for some targets.

E.g.

a = a + 4
if (b > 5) {
    bit<3> v = c + 2;
    t1.apply();
    d = 8 + v;
} else {
    if (e == 4) {
        d = 1;
        t2.apply();
        c = 2
    }
}

====>

splitting on table calls:
before:

a = a + 4
cond_1 = b > 5;
if (cond_1) {
    v = c + 2;
} else {
    cond_2 = e == 4;
    if (cond_2) {
        d = 1;
    }
}

after:

if (cond_1) {
    t1.apply();
    d = 8 + v;
} else {
    if (cond_2) {
        t2.apply();
        c = 2
    }
}

and finally hoisted declarations:

bool cond_1;
bool cond_2;
bit<3> v;

[fruffy]

Would try to enable this with p4test just to see whether there are any failures. Excluding ref file mismatches ofc.

Edit: Oh I see, this is a very targeted pass. Hard to test broadly. In your example, the input would be the particular table.apply() method call statements?

[vlstill]

Would try to enable this with p4test just to see whether there are any failures. Excluding ref file mismatches ofc.

Edit: Oh I see, this is a very targeted pass. Hard to test broadly. In your example, the input would be the particular table.apply() method call statements?

Yes, it is not even a pass that is exposed, just the function. Intended to be used in other passes.

In the example, condition would be something like

[](const auto *stmt, const auto *) {
  if (const auto *mcs = stmt->to<IR::MethodCallStatement>()) {
    if (const auto *apply = P4::MethodCall::resolve(mcs, refMap)->to<P4::ApplyMethod>()) {
      return apply->apllyObject->is<IR::P4Table>();
    }
  }
  return false;
}

[ChrisDodd]

We generally prefer C++ for statements like

for (auto &el : bc->components) {

here the & in only necessary in a Transform/Modifier where you're changing the block statement. In an Inspector you can leave it out.

[vlstill]

yes, but I do need the index in the body of the loop, and in absence of a good range adapter like Python's enumerate, I prefer to fall back to C style loop in this cases, compared to e.g. using pointer distance to recover the index.