Move dead code removal in lower after last updategraph #69421
Conversation
ghost
assigned 
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
|
Tagging subscribers to this area: @JulieLeeMSFT Issue DetailsWe perform "dead code removal" pass just before "gc poll insertion", but we should do it just after the last
See #69041 (comment) and #69041 (comment) for details.
|
|
There are few regressions in minopts because earlier we would always do dead code removal, but with this change, we would do it only if optimizing. |
|
@dotnet/jit-contrib , @AndyAyersMS - any thoughts? |
Is there any reason it shouldn't done be in minopts as well? |
Not really. I think I should do it regardless, just like we do today. |
|
I agree. I don't see removing dead code as an optimization. |
| @@ -6393,12 +6393,19 @@ PhaseStatus Lowering::DoPhase() | |||
| { | |||
| comp->optLoopsMarked = false; | |||
| bool modified = comp->fgUpdateFlowGraph(); | |||
| modified |= comp->fgRemoveDeadBlocks(); | |||
There was a problem hiding this comment.
If fgUpdateFlowGraph returned false, do we need to run this?
There was a problem hiding this comment.
Yes. This should be run regardless (as we do today). I want to do it after update flow graph because it might make more blocks eligible for removing.
|
@dotnet/jit-contrib - can someone sign off so we can unblock the verification of #69041 (comment)? |
|
Possible improvements seen on ARM64 (may be autofiling dups?) |
We perform "dead code removal" pass just before "gc poll insertion", but we should do it just after the last
updateFlowGraph()happens which is inside lower. This PR moves the phase into lower eliminating some other dead blocks that were left behind because of which LSRA adds resolution moves in them.See #69041 (comment) and #69041 (comment) for details.