You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, the lambda value specialization assumed that a lambda with jit_variable in its capture list would be immediately called--which is typically the case for portability layers like RAJA. However, if a user declared multiple lambdas on the stack, and launched them in any order, the first launched lambda would register all calls to jit_variable as its own. This did not create correctness issues, but did result in Proteus failing to specialize for user-provided runtime constants for all but the first declared lambda. lambda_spec_test shows this
This PR is a bugfix, but it significantly changes how our lambda runtime value specialization works. Roughly, ProteusPass now uses use-def analysis to associate a jit_variable call --> class.anon type emitted by clang. We change register_lambda to force an allocation of the same class.anon type. Using this pattern, we can associate jit_variable-->demangled, clang emitted lambda name. Then, we can intercept execution of these lambdas at runtime, using the appropriate runtime values.
38 | int zero = 0;
| ^~~~
| Zero
39 | int one = 1;
40 | int two = 2;
41 |
42 | auto zero_lambda = [=, c = proteus::jit_variable(zero)] ()
| ~~~~
| Zero
39 | int one = 1;
| ^~~
| One
40 | int two = 2;
41 |
42 | auto zero_lambda = [=, c = proteus::jit_variable(zero)] ()
43 | __attribute__((annotate("jit"))) { printInt(c); };
44 |
45 | auto one_lambda = [=, c = proteus::jit_variable(one)] ()
| ~~~
| One
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, the lambda value specialization assumed that a lambda with
jit_variablein its capture list would be immediately called--which is typically the case for portability layers like RAJA. However, if a user declared multiple lambdas on the stack, and launched them in any order, the first launched lambda would register all calls tojit_variableas its own. This did not create correctness issues, but did result in Proteus failing to specialize for user-provided runtime constants for all but the first declared lambda.lambda_spec_testshows thisThis PR is a bugfix, but it significantly changes how our lambda runtime value specialization works. Roughly,
ProteusPassnow uses use-def analysis to associate ajit_variablecall -->class.anontype emitted by clang. We changeregister_lambdato force an allocation of the sameclass.anontype. Using this pattern, we can associatejit_variable-->demangled, clang emitted lambda name. Then, we can intercept execution of these lambdas at runtime, using the appropriate runtime values.