JIT: Fix placement of loop exit blocks in handler regions #107582
Conversation
|
/azp run runtime-coreclr libraries-pgo |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-coreclr libraries-pgo |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@dotnet/jit-contrib PTAL, libraries-pgo isn't hitting the assert anymore. Thanks! |
src/coreclr/jit/jiteh.cpp
Outdated
| void Compiler::ehUpdateLastHndBlocks(BasicBlock* oldHndLast, BasicBlock* newHndLast) | ||
| { | ||
| assert(oldHndLast->hasHndIndex() && BasicBlock::sameHndRegion(oldHndLast, newHndLast)); | ||
| unsigned XTnum = oldHndLast->getHndIndex(); |
There was a problem hiding this comment.
Seems like you should also assert that we do at least one update (that is, that oldHndLast is indeed the last block of its enclosing handler region).
| // Notes: | ||
| // It is the responsibility of the caller to set the new block's handler index, | ||
| // if it is being inserted into a handler region, too. | ||
| // |
There was a problem hiding this comment.
Why do we not just always do the handler fixup?
There was a problem hiding this comment.
If we have a funclet section, and the try region we're inserting into is in a handler region, then it makes sense to always extend the handler region too. But if we don't have funclets, and we have a try region that contains a handler region ending on the old last try block, do we want to extend the handler region to cover the new last try block? The previous block check at the fgNewBBatTryRegionEnd is meant to fix the former scenario, but I suppose it's also (inadvertently) covering the second scenario too, and it hasn't given us problems yet. I'll try your suggestion and consolidate the new helper into this one.
There was a problem hiding this comment.
Without thinking about it too much, and without enough context... why are all these helpers better than the existing fgNewBBinRegion?
There was a problem hiding this comment.
fgNewBBinRegion does a lot of extra work to try to insert the new block in the correct region without breaking up any existing fallthrough -- most of this complexity is hidden in fgFindInsertPoint. Ideally, we wouldn't worry about block ordering at all when creating new blocks, and deferring all ordering to block layout wouldn't interfere with intermediate phases. My goal of adding this new helper is to eventually phase fgNewBBinRegion out with it such that all block creation logic is ordering-agnostic, and refactor any phases that prematurely rely on block ordering.
|
/azp run runtime-coreclr libraries-pgo |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
|
Fixes #107524. When canonicalizing loops, it's possible for the loop to be in a try region with a finally handler, and for that try region to be nested in a handler region. So if we insert a new exit block into the try region, we need to set the block's handler region, and update the end pointer for the handler region, if applicable.