[LLVMdev] Forcing basic blocks to end with no more than one branch instruction?

Daniel M Gessel gessel at apple.com
Wed Oct 15 12:37:04 PDT 2008


On Oct 15, 2008, at 2:52 PM, Dale Johannesen wrote:

>
> On Oct 15, 2008, at 11:38 AMPDT, Daniel M Gessel wrote:
>
>> I'm analyzing the basic blocks of MachineInstructions that LLVM
>> generates for my TargetMachine to try to reconstruct high-level flow
>> control.
>>
>> I misunderstood the isTerminator property of an instruction to mean
>> that it had to be at the end of a basic block, but now I've seen
>> blocks that end with a conditional branch followed by an  
>> unconditional
>> branch.
>>
>> I'm sure this depends somewhat on my target, but can there be an
>> arbitrary number of conditional branches before that last branch? How
>> about before a return?
>
> Right now, the interface assumes that a block ending with a branch
> has at most two successors (see AnalyzeBranch for example).
> There are also switch tables, which can handle some cases of what you
> want.

I did notice this in the PPC AnalyzeBranch, but I wasn't sure if PPC  
did something special.

So, it sounds like I can only have 2 successors at the end of a block  
(cond, uncond)?

Or will switch tables appear sometimes and confound me with cond,  
cond, cond ... uncond? I've already set the "can't handle indirect  
branches" bit.

>
>> Before I dive in and generalize my analysis (probably only a minor
>> pain), is there any way I can get LLVM to generate BBs that are
>> constrained to use only one terminator instruction?
>
> Not now, and it would be a fairly pervasive change.

Yeah, I figured. OTOH, if it was possible I'd be kicking myself if I  
didn't ask.

If I only have to deal with 2 successors, then I can treat it as a  
special case: backward branches become loops, so two backward branches  
would be two loops - something I can patch in.

If I have more than two successors, I think I'll have more success by  
only dealing with a single branch at a time and going finer grained  
than basic blocks.

I'm still thinking that through....

Thanks,

Dan






> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list