Print the state when the align instructions don't match up#83286
Print the state when the align instructions don't match up#83286kunalspathak merged 7 commits intodotnet:mainfrom
Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch, @kunalspathak Issue DetailsIn #82729, we hit a problem where we have
|
|
@dotnet/jit-contrib |
|
Didn't we recently make some change to SPMI to hide diffs from alignment changes? Seems like you might want to run asmdiffs locally with this disabled to be sure nothing unexpected is happening. |
|
yes, I forgot about it. pushed. |
|
This reverts commit c10b70d.
| block->bbNatLoopNum, bNext->bbNatLoopNum); | ||
| block->bbNatLoopNum = bNext->bbNatLoopNum; | ||
| } | ||
|
|
There was a problem hiding this comment.
Should we also update the loop table -- presumably this loop now has a new top? Or can this only happen when we no longer are maintaining the loop table?
There was a problem hiding this comment.
We do update loop table by calling fgUpdateLoopsAfterCompacting() below.
In #82729, we hit a problem where we have
aligninstruction for a loop that also contains analigninstruction for a different loop. This state is not permitted. So, print the state of loops with relevant information.Most likely, the fix for such cases would be inThis was happening because during block compaction, we were failing to update theplaceLoopAlignInstructions()but it is hard to determine the missing case without a repro.bbNatLoopNumof a blockAinto which the other blockBis getting compacted into. BlockBturned out to be backward jump source of a loop. BlockAwas placed lexically before the top-loop. InplaceLoopAlignInstructions(), we handle such situations where if we see a loop body before the loop-top, we disregard such loop from getting aligned, but sincebbNatLoopNumwas not up to date, we were failing to recognize it. With the fix, we will unmark such loops from participating in alignment.Fixes: #82729