[LLVMdev] Multiple successors, single dynamic successor

Michael Ilseman michael at lunarg.com
Tue Aug 2 13:17:45 PDT 2011


I see, you want to combine identical sequences of instructions by
making a BasicBlock for them, while preserving the semantics of the
original program, correct? Could you just add a PHINode to the top of
the new BB denoting what path it took to get there, and have the new
BB's terminator be a switch on that PHI? That's the only way I know of
for representing that sort of thing, but someone else here might know
more. If you choose to implement it that way,
include/llvm/Transforms/Utils/BasicBlockUtils.h would be helpful to
you, particularly the SplitBlock function.

On Tue, Aug 2, 2011 at 2:01 PM, Carlo Alberto Ferraris
<cafxx at strayorange.com> wrote:
>
>
> Nella citazione martedì 2 agosto 2011 20:02:08, Michael Ilseman ha scritto:
>>
>> I'm assuming that you're talking about a situation where this can't be
>> determined statically in the existing LLVM IR, but you know it's true
>> and want to put it in (e.g. you're the one generating LLVM IR).
>
> Correct. Or, more precisely, I'd like to investigate macro compression, i.e.
> finding duplicate sequences of instructions and merging them together.
> Suppose you have two fragments in the cfg like this: a -> b -> c and d -> e
> -> f. Suppose that basic blocks b and e are identical: macro compression
> would discard e and have the second fragment transformed like this: d -> b
> -> f.
> b has now two predecessor (a and d) and two successors (c and f), but we
> know that when control comes from a we will always have to jump to c and
> when coming from d we will always jump to f (basically we could say that
> macro compression is the inverse of jump threading). 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.
>
> --
> 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