JIT: avoid cloning mid-entry loops with multiple non-loop entry preds #70959
Conversation
If a mid-entry loop has several non-loop preds, some of them may be edges from enclosing loop constructs that were not recognized as loops on their own. Avoid cloning such loops. We won't do proper invariance anlysis as we are not properly recognizing the extent of the loop as is, and we won't get the flow connnected up properly post cloning (so that the fast loop is proper loop where the entry is dominated by the head). This is a workaround for a fairly rare case. Such loops are never iterable and so we will only try cloning when these loops have an invariant type test. Ideally we would extend loop canonicalization to cover this case, essentially ensuring that all recognized loops have a preheader -- that is, that the entry has just one non-loop predecessor. Currently we do this only for top entry loops. But doing that with our current setup looked more complex and we don't expect to see many of these cases. Closes dotnet#70802.
dotnet-issue-labeler
bot
added
the
area-CodeGen-coreclr
ghost
assigned 
|
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch Issue DetailsIf a mid-entry loop has several non-loop preds, some of them may be edges from Avoid cloning such loops. We won't do proper invariance anlysis as we are not This is a workaround for a fairly rare case. Such loops are never iterable and Ideally we would extend loop canonicalization to cover this case, essentially Closes #70802.
|
|
@BruceForstall PTAL No diffs. |
It would, provided we migrated the non-loop preds to the preheader. |
If a mid-entry loop has several non-loop preds, some of them may be edges from
enclosing loop constructs that were not recognized as loops on their own.
Avoid cloning such loops. We won't do proper invariance anlysis as we are not
properly recognizing the extent of the loop as is, and we won't get the flow
connnected up properly post cloning (so that the fast loop is proper loop where
the entry is dominated by the head).
This is a workaround for a fairly rare case. Such loops are never iterable and
so we will only try cloning when these loops have an invariant type test.
Ideally we would extend loop canonicalization to cover this case, essentially
ensuring that all recognized loops have a preheader -- that is, that the entry
has just one non-loop predecessor. Currently we do this only for top entry
loops. But doing that with our current setup looked more complex and we don't
expect to see many of these cases.
Closes #70802.