standard annotations on extern functions/methods #802
Conversation
There was a problem hiding this comment.
I wonder if we should try to rationalize these names a bit and perhaps signal somehow that they are for externs? I don't have any brilliant ideas, but I will observe that right now it's not clear that pure and packetState are related in any way. It could be nice if that were the case.
p4-16/spec/P4-16-spec.mdk
Outdated
| not depend on any hidden state that may be changed by other calls. | ||
| An example is the `hash` function which computes a deterministic | ||
| hash of its arguments. A `@pure` function whose results are unused | ||
| may be safely eliminated with no adverse effects, and mulitple calls |
p4-16/spec/P4-16-spec.mdk
Outdated
| hash of its arguments. A `@pure` function whose results are unused | ||
| may be safely eliminated with no adverse effects, and mulitple calls | ||
| with identical arguments may be combined into a single call. `@pure` | ||
| functions may also be reoerdered with respect to other computations |
|
I liked how |
|
I do not know if there are any useful compiler optimizations that can be made with the localState, packetState, and localIndexedState annotations. My only reason for introducing them was noticing that there are some fairly consistent restrictions of these kinds on most of the externs in v1model and PSA architectures. Some kind of name prefix would be one way to make it more obvious that these annotations are related to one another. |
| - `@noSideEffects` - Weaker than `@pure` and describes a function that | ||
| does not change any hidden state, but may depend on hidden state. | ||
| Such a function may be dead code eliminated, and may be reordered | ||
| or combined with other `@noSideEffects` or `@pure` calls, but not |
There was a problem hiding this comment.
If we do not know when the hidden state may be mutated this may make reordering difficult.
Perhaps we want to discuss also @synchronous and @asynchronous annotations, because I suspect that noSideEffects functions are only allowed to operate on state that is changed synchronously - by other operations invoked explicitly from the dataplane.
There was a problem hiding this comment.
I am happy to discuss the meaning of synchronous and asynchronous annotations, as it isn't clear to me yet what they are intended to mean, at least not in a precise covers-all-cases kind of way.
I am assuming that a compiler can never really use one of these proposed annotations in isolation and assume it can do safe optimizations based only upon that, but most know globally about the effects of all possible methods on an extern.
Does that change the meaning of the proposed @nosideeffects annotation, though? Or is it a caution to compiler optimization pass writers, who are hopefully already a cautious group of folks? :-)
| accessed state is limited to state associated directly with the extern | ||
| object instance on which the method is called. When applied to an extern | ||
| function, the accessible state is restricted to state associated directly | ||
| with this extern function. Method and function calls so annotated will |
There was a problem hiding this comment.
I suspect that for extern functions you imply that they operate on a "singleton" instance of an implicit built-in extern?
There was a problem hiding this comment.
That is the meaning I was trying to convey by the sentence "When applied to an extern function, the accessible state is restricted to state associated directly with this extern function."
There was a problem hiding this comment.
Yes, that is essentially what I was trying to say here. Not clear if introducing the concept of an implicit singleton makes it clearer or less clear though.
| being processed by the P4_16 code that made the method/function call. An | ||
| annotation of `@packetState` implies an annotation of `@localState`. | ||
|
|
||
| - `@localIndexedState` - Similar to `@localState`, except it is even |
There was a problem hiding this comment.
I think that all these would benefit from at least an example.
I am not sure that the compiler can really take much advantage of the localIndexedState if nothing more is said about the partitioning index and how it is used as a function parameter.
There was a problem hiding this comment.
Before writing examples in the spec, I think it is better to consider leaving localState, localIndexedState, and packetState out of the spec, if they have no known use cases for enabling compiler optimizations. I do think the ideas behind them are useful for documentation purposes, whether they are annotations in the language or not.
| never read, nor write, global state of the architecture, nor the state | ||
| of any other extern object instance or function. | ||
|
|
||
| - `@packetState` - Similar to `@localState`, except it is even more |
There was a problem hiding this comment.
I wrote this comment on the compiler PR:
It looks to me like we may want this annotation to be on the extern itself rather than on each method.
Does it ever make sense to have only some methods of an extern be @packetState?
There was a problem hiding this comment.
I do not know if it ever makes sense to have only some methods of an extern be @packetState and not others.
I can say that in v1model and PSA architectures, the only ones that exist where @packetState appears correct are:
- some of the extern functions
- for PSA's Checksum, Digest, and InternetChecksum externs, where it does apply to all methods of the extern, not only some of them.
Details are in this article, where you can look for yes's in the @packetState column of the two tables: https://github.com/jafingerhut/p4-guide/tree/master/extern-annotations
Again, before we try to make localState, localIndexedState, and packetState more precise in the spec, better to decide whether we should leave them out of the spec, at least for now, until and unless they are deemed useful for compiler optimization passes.
There was a problem hiding this comment.
I can't at the moment think of an extern where we might want different annotations on different methods, but I'm not sure moving it to the extern (requiring all methods of an extern to be the same) really buys us anything (and it makes the implementation a little more cumbersome.)
|
One thought from WG discussion -- would users want to put these annotations on any of their functions? Since the compiler always has the function bodies available for analysis, it does not need them, but perhaps the user might signal their intentions with the annotations? Then if the compiler determines they are not met (ie finds a side effect in a @nosideeffects function) it could issue a diagnostic. |
|
|
|
We decided to close this issue at the 2/7/22 LDWG as |
No description provided.