-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Flow graph successors representation for BBJ_EHFINALLYRET #84278
Comments
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsThe
Note that there can be multiple Note also that if the finally is known to never return (due to an unconditional The "flowgraph successors" of the Currently, the JIT does not directly represent the BasicBlock successors of a Can we directly represent the This would make forward Note that the IR is asymmetric here: the @AndyAyersMS @dotnet/jit-contrib Comments?
|
Related: #84307 -- "Consider adding BBJ_EHFAULTRET" |
Currently, BBJ_EHFINALLYRET blocks have no explicit successors in the IR. To implement successor iteration, a very expensive process is followed to (1) find the region of blocks where a BBJ_CALLFINALLY block calling the `finally` might be found, (2) search the region for such blocks, and (3) return as a successor all the BBJ_ALWAYS blocks in the corresponding BBJ_CALLFINALLY/BBJ_ALWAYS pair. Change the IR to explicitly represent and maintain this list of successors for BBJ_EHFINALLYRET blocks. The representation is a simple array of `BasicBlock*`, similar to how BBJ_SWITCH block targets are represented. Fixes dotnet#84278 Notes: 1. The BBJ_EHFINALLYRET successors are computed in `impFixPredLists()`. There are various dumpers that run before this, so we need to tolerate incomplete successor information in some places. 2. `ehGetCallFinallyBlockRange()` is still used by some code. I changed the semantics to return a `[first..last]` range inclusive of `last` instead of the previous `[beginning..end)` range exclusive of `end`. This makes it easier to use with our BasicBlock iterators.
* Explicitly represent BBJ_EHFINALLYRET successors Currently, BBJ_EHFINALLYRET blocks have no explicit successors in the IR. To implement successor iteration, a very expensive process is followed to (1) find the region of blocks where a BBJ_CALLFINALLY block calling the `finally` might be found, (2) search the region for such blocks, and (3) return as a successor all the BBJ_ALWAYS blocks in the corresponding BBJ_CALLFINALLY/BBJ_ALWAYS pair. Change the IR to explicitly represent and maintain this list of successors for BBJ_EHFINALLYRET blocks. The representation is a simple array of `BasicBlock*`, similar to how BBJ_SWITCH block targets are represented. Fixes #84278 Notes: 1. The BBJ_EHFINALLYRET successors are computed in `impFixPredLists()`. There are various dumpers that run before this, so we need to tolerate incomplete successor information in some places. 2. `ehGetCallFinallyBlockRange()` is still used by some code. I changed the semantics to return a `[first..last]` range inclusive of `last` instead of the previous `[beginning..end)` range exclusive of `end`. This makes it easier to use with our BasicBlock iterators. * Review suggestions
The
try
of atry / finally
clause can contain a set ofleave
IL specifying to where the code should continue after thefinally
is invoked. The JIT transforms this into IR like:Note that there can be multiple
leave
IL that require invoking the same finally, and thus multipleBBJ_CALLFINALLY
targeting the same finally. Each of the correspondingBBJ_ALWAYS
(continuation) targets can be different, however.Note also that if the finally is known to never return (due to an unconditional
throw
or infinite loop), theBBJ_CALLFINALLY
will not have aBBJ_ALWAYS
and the finally will not have aBBJ_EHFINALLYRET
.The "flowgraph successors" of the
BBJ_EHFINALLYRET
block are all theBBJ_ALWAYS
blocks corresponding to theBBJ_CALLFINALLY
blocks that target the finally.Currently, the JIT does not directly represent the BasicBlock successors of a
BBJ_EHFINALLYRET
block. Finding those successors, as is done with the versions ofGetSucc/NumSucc
that take aCompiler*
, is very expensive.Can we directly represent the
BBJ_EHFINALLYRET
successors in the IR? E.g., as an array ofBasicBlock*
, the same wayBBJ_SWITCH
successors are implemented?This would make forward
GetSucc/NumSucc
flowgraph traversals much cheaper.Note that the IR is asymmetric here: the
BBJ_ALWAYS
pair ofBBJ_CALLFINALLY
has theBBJ_EHFINALLYRET
in its predecessor list.@AndyAyersMS @dotnet/jit-contrib Comments?
The text was updated successfully, but these errors were encountered: