Three minor changes

[ChrisDodd]

These relate to #367, in that they are minor cleanups that help with it, plus a test case that is problematic.

The ability to disable the SideEffectOrdering pass is a bit of a hack -- it is problematic in that it introduces too many unneeded copies that are too hard to get rid of, and isn't really necessary for most targets. It should probably be a midend pass rather than a frontend pass in the first place.

[mihaibudiu]

This pass does many important things, including making sure that the evaluation order is the one specified by the language. It takes care of many corner cases. Many subsequent passes assume that these corner cases do not happen; for example, arguments to calls never alias after this pass, so the inliner can be much simpler.

The SideEffectOrdering pass is the only pass which was specific to P4 v1. The PR #367 makes this pass independent on the source language.

Previously we could skip this pass for P4 v1 because we knew these corner cases cannot be expressed in P4-14. In general it should not be disabled for P4-16 programs - that's why it is in the front-end.

[mihaibudiu]

Please note that #367 causes the side-effect ordering to introduce many fewer copies. In fact, it will never introduce copies for P4-14 programs.

[ChrisDodd]

#367 introduces more copies for P4_14 programs, which is the problem. Particularly it introduces extra copies for parser lookahead.

[mihaibudiu]

In general the copies are necessary to correctly generate code for bmv2. The language supports expressions which are too complicated for bmv2 to handle directly in select expressions, e.g.:
select(a.b, p.lookahead<H>().x)

In general, the back-end should be prepared to handle lookahead that reads into temporaries.
I think that the right approach is to teach the copy propagation pass about lookahead.

There are also some subtle issues related to exceptions and how much you readahead.

[mihaibudiu]

I approve all changes, but I expressed my opinion with respect to the sideEffects.

It was a lot of work to make the bmv2 back-end work with the sideEffects changes, so I expect it will take some work with other back-ends. But the BMv2 back-end didn't really support the language in its full generality; the back-end is now much more powerful. That's why I could actually delete some code from that back-end, which was handling lookahead in a special way.

For example, users can write expressions involving lookahead, and the json generated will be correct. We are not relying on lookahead being only invoked within a select.

[cc10512]

please try to resolve the PI submodule changes before merging.