JIT: Propagate LCL_ADDRs into handlers #109182
Conversation
Expand the support for LCL_ADDR propagation to keep assertions around in handler blocks when they are true at all points in all predecessor blocks of those handlers. This requires keeping track of the "always true" assertions for each block.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
|
cc @AndyAyersMS |
|
It seems like we could avoid storing both sets of assertions if we pushed facts into successors instead of pulling them from predecessors; then at the end of each block we would just intersect the regular successor's "assertions-in" set with the block's "assertions-out" set, and the EH successor's "assertions-in" set with the block's "always-assertions" set. However, it would add a visit to all block's successors, and we wouldn't be able to remove the loop over predecessors since it's still needed to know if this block is a target of a backedge. If the DFS traversal saved the targets of backedges we would be able to avoid the loop over the pred list (and loop finding could use it to directly find header candidates). But overall it seems simpler to just stick to the current approach and store an extra 8 bytes per basic block, which is a very small amount of memory anyway. |
|
cc @dotnet/jit-contrib PTAL @AndyAyersMS |
Expand the support for LCL_ADDR propagation to keep assertions around in handler blocks when they are true at all points in all predecessor blocks of those handlers. This requires keeping track of the "always true" assertions for each block.
For context, see discussion around #102965 (comment)