allow disabling of subtraction transform

[grg]

Add mechanism to allow the the transform that changes a - const -> a + (-const) to be disabled.

This change adds a new function to the FrontEndPolicy object to control this optimization. We may eventually want to change to some other mechanism (e.g., breaking out some of the optimizations that aren't universally useful), but for now this provides the ability to turn the optimization off.

[fruffy]

I think GCC/CLang-style feature flags might be preferable over adding a policy to each compiler pass.

[vlstill]

@grg, out of curiosity can you share motivation for disabling this rewriting?

These changes are increasingly showing that the current frontend/midend split is not really working. Indeed even which frontend optiomizations disabled, it does actually a lot of optimizations and not really necessary rewriting (constant folding, parser-if elimination, control flow simplications). One path forward I could see would be to start definting a "minimal frontend" that would be basically responsible of checking validity of the program, including type checking but would not very little rewriting. It might be tricky to say where the limits should be (inserting casts explicitly is probably OK, expanding the ... default values likely too, but constant folding or removal of useless casts is not OK I'd say). SideEffectsOrdering is probably also outside of frontend. Then we could define the exiting frontend to start with these passes and the targets that want would switch to the new frontend and move all the optimizations they want to midend.

What could get tricky is that some midend passes may have implict preconditions that the current frontend (some pass from it) had already executed.

[vlstill]

How does this affect constant folding, is the pass able to handle subtract of constants?

Otherwise the code looks good to me ✅.

[grg]

@vlstill A simple array reference of this form (where depth is a 2 bit field):

hdrs.ipv4[meta.common.depth-1]

is translated to:

hdrs.ipv4[meta.common.depth + 2w3]

The Intel IPU compiler reports an error after this translation is applied. Without knowing the history, my guess is that the original code author wanted to prevent access beyond the current depth by disallowing any addition to the depth. After the frontend has executed and applied this transformation, we don't know whether the P4 author wrote depth - 1 or depth + 3.

I agree that defining a new minimal front-end is a good way to proceed. Some existing passes will neatly fit either in-or-out of the minimal front-end, but I suspect that there will be some passes that need splitting.

[ChrisDodd]

These changes are increasingly showing that the current frontend/midend split is not really working. Indeed even which frontend optiomizations disabled, it does actually a lot of optimizations and not really necessary rewriting (constant folding, parser-if elimination, control flow simplications).

The genesis of this (doing "too much" in the frontend) is allowing bit<expr> where expr is any expression that can be reduced to a constant. We need that in order to do typechecking properly (which we want in the frontend), so we end up needing inlining (in case the expression calls some function), which in turn brings in lots of other requirements as well.

One possibility is that we set things up to do these passes that should not be in the frontend only in limited contexts (like type arguments) when running in the frontend, so as to allow proper typechecking, without doing everything that any target might not like. Then targets could run them (or not) in the midend as desired.

What could get tricky is that some midend passes may have implict preconditions that the current frontend (some pass from it) had already executed.

This is already a general problem -- many passes depend on some other pass having been run first, and it is not well documented. Passes that have preconditions should at least document those preconditions.