[PATCH] D81494: [GVN] Do not try to split critical edges with indbr preds in loop.

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 10 09:20:47 PDT 2020


fhahn added a comment.

In D81494#2083191 <https://reviews.llvm.org/D81494#2083191>, @efriedma wrote:

> There's a separate bailout "COULD NOT PRE LOAD BECAUSE OF INDBR CRITICAL EDGE" earlier, so any block in the CriticalEdgePred has a non-indirectbr terminator.  However, if LoadBB has any predecessor which is an indirectbr, even if it's not the edge we want to split, the call to llvm::SplitCriticalEdge fails.  This is because it's trying to do something more than just split the critical edge.  I guess here, it's trying to preserve LoopSimplify form: %exit is an exit block, so it should only have predecessors inside the loop.


Exactly! Sorry for not making it clear in the description.

> It should be possible to preserve the invariant here.  For the testcase, the resulting function looks something like the following.  We create a new basic block `exit.latch1` to split the edge.  Then we split `exit` at the beginning of the block, before any non-PHI instructions.  Then `exit.latch1` branches to the split block.  (See also llvm::SplitIndirectBrCriticalEdges.)

Right, that should work. I tried, but unfortunately it means moving instructions to a different block & potentially introducing new PHIs and some users of SplitCriticalEdge do not seem to like it (especially the MemoryDependenceAnalysis caching....). I've put up the patch there D81584 <https://reviews.llvm.org/D81584>, but some of the issues are not resolved yet (and I am not sure if it is the best way forward at the moment, given that users seem not prepared for instructions being moved).

> I'm a little skeptical it's a good idea to bail out of GVN, as opposed to fixing SplitCriticalEdge.  If SplitCriticalEdge was private to GVN, maybe it would be okay.  But as it is, I think it's a ticking time bomb if SplitCriticalEdge "randomly" crashes on certain edges due to undocumented constraints.

yes it seems a bit odd to have the check here in GVN. I've put up D81582 <https://reviews.llvm.org/D81582>, which updates SplitCriticalEdge to return nullptr before making any changes, if it would have to split a block with a `indirectbr` terminator. That should ensure we do not run into the crash for other users. GVN itself seems to bail out on blocks it *things* SplitCriticalEdge cannot handle, but that seems a bit fragile in general.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D81494/new/

https://reviews.llvm.org/D81494





More information about the llvm-commits mailing list