JIT: More precise side effect propagation in loop hoisting#118736
JIT: More precise side effect propagation in loop hoisting#118736amanasifkhalid wants to merge 1 commit intodotnet:mainfrom
Conversation
github-actions
bot
added
the
area-CodeGen-coreclr
There was a problem hiding this comment.
Pull Request Overview
This PR improves the precision of side effect propagation during loop hoisting optimization in the JIT compiler. The change replaces a simple boolean flag with a more sophisticated bit vector approach to track which blocks have encountered side effects.
- Replaces the
m_beforeSideEffectboolean field with am_sideEffectBlocksbit vector - Tracks side effect state per block rather than globally across the entire loop
- Propagates side effect state to successor blocks when side effects are encountered
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
cc @dotnet/jit-contrib, @AndyAyersMS PTAL. Diffs show PerfScore improvements outnumbering regressions in most collections, except for |
AndyAyersMS
left a comment
AndyAyersMS
left a comment
There was a problem hiding this comment.
Approving but would still like to see some examples where this will resolve current perf issues.
|
@EgorBot --arm --filter |
|
@AndyAyersMS I'm not seeing as much impact in the microbenchmarks as I hoped for, mainly because this seems to impact the OSR variants of various benchmarks instead of their Tier 1 variants. Since this change looks riskier than #118463, I'm ok with holding off on this. |
Sure, makes sense. Thanks for checking. |
|
@AndyAyersMS, is this ready to merge? |
|
We backed out a previous change so I'd say no. We need to look at that one and this carefully. |
Follow-up to #118463. As we walk a loop's blocks in RPO, propagate the side-effecting nature of each block to its successors, rather than flipping a single flag once side-effecting code is encountered.