[llvm-dev] question on analyzeBranch and getFallThrough (original) (raw)

Bagel via llvm-dev llvm-dev at lists.llvm.org
Sun Jul 12 11:03:03 PDT 2020

Excellent diagnosis! I had marked the jump table instruction "isBarrier = 1". When I removed that, no assertion.

Thanks for the quick fix, Brian

On 7/11/20 8:16 PM, James Y Knight wrote:

On Thu, Jul 9, 2020 at 5:32 PM Bagel via llvm-dev <llvm-dev at lists.llvm.org_ _<mailto:llvm-dev at lists.llvm.org>> wrote: I am working on a back end for an architecture whose jump via table instruction includes the range check. If the index is out of range, the jump table instruction just falls through.  I implemented a pass to remove the range check generated before the jump table instruction because it is superfluous. This causes as assertion in MachineBlockPlacement.cpp:  assert((!TII->analyzeBranch(*PrevBB, TBB, FBB, Cond) ||  !PrevBB->canFallThrough()) && "Unexpected block with un-analyzable fallthrough!"); This should not be possible, because blocks which might fall-through and where analyzeBranch said "i dunno" were placed into the BlocksWithUnanalyzableExits set, checked right before that assert. The method MachineBasicBlock::getFallThrough() uses TII->analyzeBranch(). Using analyze branch there doesn't appear to be anyway to signify that a branch is not a simple conditional or a simple indirect but rather a combination of the two -- it conditionally branches indirect or falls through. analyzeBranch should be returning "I dunno" (aka true) for this block, in which case getFallThrough should indicate that the block might fall through. The only other reason getFallThrough wouldn't return a block, is if your block successors are incorrect, or if the last instruction in the block (maybe your jump table instruction) is incorrectly marked as "isBarrier = 1", despite being able to continue. Is there a way to express this with analyzeBranch? Can I override the method getFallThough? Is there a way to annotate a basic block to indicate in can fall through? It would seem this would save a lot of calls to analyzeBranck I'm working on a change to do this, but that's independent to your issue.

More information about the llvm-dev mailing list