-
Notifications
You must be signed in to change notification settings - Fork 1.7k
VM: enable OSR in block expressions #36421
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
Labels
area-vm
Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
Comments
This was referenced Apr 1, 2019
Great example! Something like @NeverInline
List<int> foo(int n) {
var x = z.bar(42, bazz(), 'abc', [more_bazz(), for (int i = 0; i < n; i++) 2*i ]);
return x;
} passes without OSR in block expr
but when OSR inside the block expression is enable as well, it crashes (segfault in release mode, the following assertion in debug mode).
|
dart-bot
pushed a commit
that referenced
this issue
Apr 3, 2019
Rationale: The "unoptimized code" representation is really a stack machine that pushes and pops arguments. The intermediate representation did not show the correct labeling for "temporaries", in particular around push arguments. This CL fixes that bug, making the human readable form of the intermediate much easier to understand. Also, it allows for proper stack depth computations. First use: Sharpen condition on OSR points a bit. Simple control flow collections will now allow OSR. #36421 #36409 Change-Id: I8be707af08462a22687b355b747ba85e42431ad5 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98500 Commit-Queue: Aart Bik <[email protected]> Reviewed-by: Vyacheslav Egorov <[email protected]> Reviewed-by: Martin Kustermann <[email protected]> Reviewed-by: Alexander Markov <[email protected]>
dart-bot
pushed a commit
that referenced
this issue
Apr 3, 2019
Rationale: We should test for *empty* stack. As written, we basically never generate OSR points for the bytecode path except for the cases we can' handle yet :-) #36421 Change-Id: Ie70a626f9fd24d63442e681ab120087f9d1b010b Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98625 Reviewed-by: Alexander Markov <[email protected]> Commit-Queue: Aart Bik <[email protected]>
dart-bot
pushed a commit
that referenced
this issue
Apr 10, 2019
Rationale: This enables OSR even in the presence of block expressions, which are introduced by the new CFE control-flow collections and spread operations. Faster is better! #36421 #36218 #36214 Change-Id: I363a0b0a5becbbd5743f8fb47ff24dcebc0e4d64 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/98744 Commit-Queue: Aart Bik <[email protected]> Reviewed-by: Alexander Markov <[email protected]>
OSR is now working in all cases, including control-flow collections that leave a non-empty expression stack in an OSR point (for both kernel and bytecode paths). |
dart-bot
pushed a commit
that referenced
this issue
Apr 18, 2019
Rationale: Test was borderline timeout. The reduced tripcount still triggers OSR consistently, but runs a lot faster. #36421 #36218 #36214 Change-Id: I60917bb6bdd51dee6bd11d1fe5beede4753c2147 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99783 Reviewed-by: Siva Annamalai <[email protected]> Commit-Queue: Aart Bik <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area-vm
Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
The current VM implementation of block expressions disables OSR while inside a block expression to avoid some issues with temps on expression stack. This is okay for a first implementation, since widget loops inside control flow collections can be expected to be short running. However, for a high quality implementation, we should enable OSR even inside those blocks, since it is always possible to write a contrived long running loop. This bug tracks the progress of that work.
Probably biggest VM item left to be explored is enabling OSR points inside control flow collection for loops. Alex notes we should ensure that temporaries on the expression stack are preserved when OSR happens.
Consider a more complex expression like
var x = x.bar(42, bazz(), 'abc', [more_bazz(), for (int i = 0; i < n; i++) 2*i ]);
In this case x, 42, bazz() and 'abc' should be on the expression stack unless CFE introduces temporary variables for them. Let's:
(1) test if the above example works;
(2) dump kernel to see how CFE generates this;
(3) print flowgraph of a function compiled for OSR and check that it loads captured values correctly.
The text was updated successfully, but these errors were encountered: