[P4Testgen] Run typechecking after front and mid end. #4834
Conversation
fruffy
force-pushed
the
fruffy/testgen_typechecking
branch
2 times, most recently
from
f496c1d
to
4f16467
Compare
fruffy
force-pushed
the
fruffy/testgen_typechecking
branch
from
4f16467
to
2066243
Compare
There was a problem hiding this comment.
There is no invariant enforcing well-typedness of the program.
yep. I was thinking we should have a way to turn something like that for debug build. The hardest part is probably where it should run, as in some cases there can be a set of passes that between them don't have well-typed P4 and it becomes well-typed only at the end.
| /// Add passes that break type checking. These passes may involve IR modifications the front | ||
| /// end type checker does not recognize. | ||
| virtual void addNonTypeCheckingPasses(); |
There was a problem hiding this comment.
What is the problem here? It seems very suspicious to have IR that does not type check. If this is because of custom IR nodes, it might be better to use a derived type check that supports them. Or at least (for now?) comment more on the reasons why this does not type check.
There was a problem hiding this comment.
All the passes contained in this list perform transformations that are useful for the interpreter but TypeChecking can fail on.
The two most problematic ones is the HSIndexSimplifier which converts array indices to members and ConvertVarbits which creates a new varbit type that is not recognized.
CastBooleanTableKeys converts boolean table keys to bit<1>, which type checking also might not support (I have not checked).
All these passes could be handled in the interpreter but it might be a fair bit of work.
Signed-off-by: fruffy <[email protected]>
fruffy
force-pushed
the
fruffy/testgen_typechecking
branch
from
2066243
to
80bcd03
Compare
Ensure that the program is still well-typed at this step. In some scenarios it can happen that a front or mid end pass leaves typing information incomplete or inaccurate which requires a rerun of type checking. There is no invariant enforcing well-typedness of the program.