[LLVMdev] Multiple successors, single dynamic successor

Michael Ilseman michael at lunarg.com
Tue Aug 2 13:46:37 PDT 2011


I think we sent our emails at the exact same time. I've never used
indirectbr, but my guess would be that the best solution doesn't
involve taking the address of a block (i.e.
BasicBlock::hasAddressTaken() returns false). Some LoopUnrolling and
BasicBlockUtils/Local utility functions don't do anything if a BB's
address has been taken, but it may not matter if SimplifyCFG
simplifies these away (it does turn indirectbr in br when it can,
don't know about switch).

Hopefully someone more knowledgeable can give you a better idea, but I
think that switch is preferable or otherwise equivalent to indirectbr.
This may not be the case if you happen to tell LLVM to run the
LowerSwitch pass (which may undo your work), but I don't think
anything runs that by default. When the IR reaches the SelectionDAG,
the SelectionDAG is capable of converting switches to jump tables (I
don't know about indirectbr).

On Tue, Aug 2, 2011 at 2:16 PM, Carlo Alberto Ferraris
<cafxx at strayorange.com> wrote:
> Nella citazione martedì 2 agosto 2011 22:01:13, Carlo Alberto Ferraris ha
> scritto:
>>
>> My question is: what is the best way to
>> express such relationships in LLVM IR ("best" in the sense of allowing
>> other optimizations to run effectively)? Bear in mind that in this example
>> N=2, but it may be way bigger than that.
>
> Just to clarify: I already figured out two ways to do it, i.e.:
>
> %0 = phi i8* [blockaddr(%succ0), %pred0], [blockaddr(%succ1), %pred1], ...
> ...
> indirectbr %0, [%succ0, %succ1, ...]
>
> or
>
> %0 = phi i8 [0, %pred0], [1, %pred1], ...
> ...
> switch %0, undef, [0, %succ0], [1, %succ1], ...
>
> what I'd like to know is which one do you think is better (and why) or if
> there are better ways I didn't think of.
>
> --
> Carlo Alberto Ferraris <cafxx at strayorange.com
> <mailto:cafxx at strayorange.com>>
> website/blog <http://cafxx.strayorange.com> - +39 333 7643 235
>
>




More information about the llvm-dev mailing list