p4lang / p4c

P4_16 reference compiler

Home Page:https://p4.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

idea: IR validator, programatic pass pre/post conditions

vlstill opened this issue · comments

I had an idea in mind for some time and #4612 (comment) make it arise once more. And I wonder if it sounds useful to more people.

Essentially the idea is to build a more powerful IR validator (or rather set of them) that could be used to programmatically specify pre- and post-conditions of IR passes or even assert that some condition should hold in some region of the IR processing (e.g. from a given point in midend to the end of midend).

Some example use cases:

  • There are no typedef and newtype introduced types in the IR.
  • There are no complex constants (i.e. constant expressions which are not literals) in the IR.
  • There are no nodes with unknown type in the IR.
  • There are no nodes with unknown type in the IR and the program is type-correct.
  • There are no return nodes in the IR.

It would be useful to have a composition helper to e.g. run a validator only on actions.

I would not strive to have all the pre/post conditions encoded this way (that would be a huge undertaking), but for some major cases it should be quite useful to have this cathing bugs and making things more explicit.

We would probably want these enabled only conditionally (e.g. in CI, but not in production) as they would take nontrivial amount of time.


Technically I could imagine having an infrastructure similar to pass manager's debug hooks for this with passes being able to specify pre- and post-conditions and ability to "push" and "pop" requirements. These would then be run in-between the regular passes. Of course, they would be required to be immutable so they can be skipped in production.


Credit: I've first heart similar idea from an intern on the Tofino compiler team.

Encoding pre- and postconditions in the compiler passes to understand what they require or produce has been a longstanding goal iirc. (cc'ing @jnfoster).

The problem is just the effort it requires. We need to understand what we expect or require from each pass and, even if we just start with basic ones (e.g., type-checking, constant-folding), it can be tedious. I unfortunately do not have the cycles to work on something like this.