p4lang
Side-effects in table actions
By this I mean not the "normal" kinds of side effects one often writes as assignments and/or function or method calls inside the body of an action, but ones that are inside of the actions table property.
This issue is related to https://github.com/p4lang/p4-spec/issues/830 but this one seems like it might be trickier, or at least different, to define the desired behavior in the specification.
If we wish to allow these, one possibility would be the following, at least for tables without an implementation property (i.e. tables without action profile or action selector implementations).
(1) table key expressions are evaluated the same as if it were done sequentially, in the order that they appear in the source code defining the table, with any side effects from one taking effect before the next table key expression evaluation is begun (there is a separate PR proposing this: https://github.com/p4lang/p4-spec/pull/834 )
(2) table lookup occurs, determining a hit or a miss, and either the hitting action to execute, or the default action should be executed if a miss occurred.
(3) If the action has expressions that need to be evaluated in the actions table property, they are effectively evaluated sequentially, after all of (1) is complete and side effects have been completed (at least for synchronous side effects).
(4) The action body is evaluated, after all of (3) is complete and side effects have been completed (again, at least the synchronous ones).
(5) copy-out of direction out and/or inout parameters of the action occur at the end of action body execution, as usual.
For tables with an action profile or action selector implementation, it seems that adding that after (1), but before (2), is the right place to add it, because those affect which action is selected. Either that or they can be seen as part of step (2).
Where "virtual functions" or "abstract functions" on tables go in the above, I haven't tried to think much about yet.
Also, all of the above could easily be a moot point, if the P4 LDWG decides that side effects in the actions table property is unwanted.
An example program demonstrating the issue is attached to this issue: https://github.com/p4lang/p4c/issues/2321
The specification says,
The expressions supplied as arguments to an action are not evaluated until the action is invoked
which seems consistent with what's written above (if a bit vague).
PR #852 is one approach to resolve this issue, following the idea of forbidding function/method calls inside of the actions table property.
I think that this PR has fixed this issue allowing indeed side-effects in action argument computations: https://github.com/p4lang/p4c/pull/2820
@mbudiu-vmw I'm confused. Doesn't https://github.com/p4lang/p4c/pull/2820 only make changes related to handling side effects in table key expressions?
I thought this issue was about side effects in the list of actions in the actions property of a table. That seems like a much more difficult thing to get right, but if you believe that p4c change also covers arbitrary side effects in table actions, let me know and I can run some crazy test programs to see if it really does work for that, too.
Reopening this issue because this p4c issue demonstrates that p4c does not support arbitrary expressions as parameters to actions within the actions property of a table: https://github.com/p4lang/p4c/issues/2835
I still think it would be reasonable if the P4 spec put restrictions on the complexity of such expressions, at least to say that table_name.apply() calls are disallowed, and perhaps the only function and/or method calls allowed should be ones annotated @pure and/or @noSideEffect, or something similarly restrictive
An alternative to my previous message: Specify that the only expressions allowed within action parameters of a table's actions property are those expressions that are also allowed within an action body. If that were done, then the compiler technique of moving the evaluations of those expressions within the body of an action would always be correct.
I am not claiming that the P4 language specification should be driven by the p4c implementation. I only wanted to point out that recently p4c was changed so that it gives a clear error message that it does not support table_name.apply().hit or .miss calls within the actions table property of a table: https://github.com/p4lang/p4c/pull/3033
p4c did not support this before that change, either -- it gave a Compiler Bug.
In the interest of tidying up the set of active issues on the P4 specification repository, I'm marking this as "stalled" and closing it. Of course, we can always re-open it in the future if there is interest in resurrecting it.