Pass to get rid of action_run() calls

[ChrisDodd]

This is a general midend pass for any target that does not support action_run directly. It rewrites the actions in a table that uses action_run to set a newly introduced metadata tmp enum that records which action was run, and changes the switch statement to use that.

It is kind-of logically the reverse of EliminateSwitch, which converts switch statements that don't use action_run() into ones that do, so it would never make sense to use both passes for a backend.

Need to update p4test so we can select which pass(es) to run in a test by some annotation in the test program to better allow testing this.

[ChrisDodd]

I've added the ability to use @command_line annotations to add command-line args in test cases, so this case actually be tested

[fruffy]

The other failures is caused by this line

p4c/backends/p4tools/modules/testgen/targets/tofino/test/p4-programs/tna_simple_switch.p4

Line 33 in c67d1fd

@command_line("--disable-parse-max-depth-limit")

This is also not a supported option for P4Testgen but the pragma is still parsed as input.

[fruffy]

I see three possible ways to solve this:

1. Since options may depend on the compiler executing the program, maybe extend this pragma with a "target"/"arch" field to ensure the option is interpreted correctly?

2. Add another option to enable/disable this pragma and adding options.

3. Or just ignore any unknown option made available by the pragma. Maybe print a warning that the option is not supported by the tool interpreting the program.

[ChrisDodd]

The other failures is caused by this line

p4c/backends/p4tools/modules/testgen/targets/tofino/test/p4-programs/tna_simple_switch.p4

Line 33 in c67d1fd

@command_line("--disable-parse-max-depth-limit")

This is also not a supported option for P4Testgen but the pragma is still parsed as input.

This line was not touched by this change, so there's no change here

[fruffy]

This line was not touched by this change, so there's no change here

It's existing code that had no impact but is now active because of https://github.com/p4lang/p4c/pull/5053/files#diff-b033ed467d2767be363300d09ff13ac0a990d2e0de7464b732d9b29888da81a1R54.

[ChrisDodd]

I modified P4COptionPragmaParser so that targets can decide whether or not they want to support @command_line option pragmas -- most real targets probably want to, but special targets like p4testgen and p4graphs possibly do not. I also remove <v1model.p4> from the testcase so p4testgen doesn't pick it up.

[fruffy]

Will be able to review the action_run pass later this week. But I'd suggest to split out the changes to P4COptionPragmaParser into a PR we can discuss separately. I think it is a cool and useful feature but it shouldn't be tagged on to this PR.

[ChrisDodd]

Will be able to review the action_run pass later this week. But I'd suggest to split out the changes to P4COptionPragmaParser into a PR we can discuss separately. I think it is a cool and useful feature but it shouldn't be tagged on to this PR.

Created #5123

[fruffy]

Could you remove the code that is related to #5123. Or do you want to rebase it on top of that PR?

Would be good to get a review from other stake holders here @kfcripps @vlstill.

[ChrisDodd]

Could you remove the code that is related to #5123. Or do you want to rebase it on top of that PR?

It requires that PR (for the testcase included here), and is (re)based on that. Ideally, that one will be approved (and merge first), then this one will rebase and become just the one change.

[fruffy]

It requires that PR (for the testcase included here), and is (re)based on that. Ideally, that one will be approved (and merge first), then this one will rebase and become just the one change.

It might take a little longer until #5123 is approved. @asl also had apprehensions.

This PR could be merged before that, given the tests pass and look ok.