[llvm-dev] question on analyzeBranch and getFallThrough
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