@command_line annotation

[ChrisDodd]

• per-target selectable support, though most should want it

[fruffy]

Would be great to show the utility with one of the existing parametrized tests.

https://github.com/p4lang/p4c/blob/main/backends/p4test/CMakeLists.txt#L118

I also think it makes sense to add target and arch as arguments to the annotation to make sure that only the right compiler picks up the option. This might make this parser safer.

[ChrisDodd]

Would be great to show the utility with one of the existing parametrized tests.
https://github.com/p4lang/p4c/blob/main/backends/p4test/CMakeLists.txt#L118

I added a @command_line to these tests (and checked that the result matches), and removed the now redundant runs from CMakeLists.txt

I also think it makes sense to add target and arch as arguments to the annotation to make sure that only the right compiler picks up the option. This might make this parser safer.

I would think it would be common to want arguments for multiple targets when you have a program that will actually compile on multiple targets. On can use #ifdef TARGET_FOO around things that you only want on a specific target, though that gets messy quickly. There's nothing terribly unsafe about these annotation, as currently they will flag an error for unrecognized command line options for the current target.

[kfcripps]

I doubt that AMD's backend would want this (I think @asl mentioned reasons that it might not be a good idea (although I don't personally have any opinion about whether it's a good or bad idea)), but as long as it's easy for a backend to toggle this annotation to off (as you've done in this PR), then I'm not opposed to these changes.

This reminds me of issue #4907. When I created it, I was thinking of having a way to specify compilation options in the source file some other way, for example via the LLVM Lit (https://llvm.org/docs/CommandGuide/lit.html) utility.

@sepanchi Sergey, have you had a chance to give any thought to this?

Maybe adding this annotation will avoid the need to use something like Lit.

[kfcripps]

Why does start get moved here in this test?

[ChrisDodd]

This is something the ParsersUroll pass does . I checked these outputs against the deleted ones in parser-unroll (which was the outputs for the tests with the explicit --loopsUnroll argument in ctest) and they match.

[kfcripps]

Are the midend outputs changing now because:

• Previously, these outputs were the result of running the corresponding tests without --loopsUnroll. The outputs in p4_16_samples_outputs/parser-unroll/ were the result of running the same set of tests with --loopsUnroll.
• Now, we are only running each of these tests one time - only with --loopsUnroll. So the set of outputs corresponding to no --loopsUnroll were deleted and replaced by outputs of the same set of tests corresponding to having --loopsUnroll.

Is that correct?

[ChrisDodd]

Yes, exactly.