-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Virtual functions should not capture the environment. #1175
Comments
Virtual functions need to be able to access arguments of the control instance that contains the extern instance defining the virtual function. The extern types themselves are generally defined at the global scope and so have no access to things like headers and metadata (instances). There's generally no fixed set of values/types that could be used as extra paramters to the virtual function; to pass things that way we'd need something like C++ template parameter packs. |
We can perhaps allow such function access read-only information, like |
Pretty much all the uses we've come up with for virtual functions so far involve them accessing dynamic information available in the static context, so I think forbidding that is a non-starter. |
What this means is that we need to have two kinds of abstract functions: some that can be analyzed, and which can capture the environment, and some which can do anything, and thus cannot. An annotation is a way to distinguish them.
This promises that all calls to |
This cannot handle something like action profile selection, because the call does not show up as P4 code. |
This is an old thread but it seems to be relevant to the discussion in #1468 |
The problem is that the table execution is done in several steps. For example, key evaluation, key lookup, selector evaluation, action execution, etc. The question is: at which moment is a specific function executed? |
That's no different from an extern function calling multiple virtual function implementations though. Or would the |
We need enough information to allow the compiler to conservatively bound the side-effects that will happen for each statement. At least for external calls that are invoked explicitly we know all the statements where the effects could happen. Tables are more complicated, for example we know the key and the actions, and we probably would need to know whether a virtual call is happening before or after the actions. We could also conservatively assume that it may happen either before or after. |
No description provided.
The text was updated successfully, but these errors were encountered: