[LLVMdev] Indirect Branch Representation

kapil anand kapilanand2 at gmail.com
Thu Jul 24 11:19:05 PDT 2008


Actually, I am trying to implement a frontend for conversion from binary to
LLVM. In binary, we would encounter branch indirect instructions like,  Br
Reg, where Reg would be an equivalent virtual register in LLVM. So, we can't
directly implement Switch block method here to represent this instruction as
we don't know how the values of Reg are mapped to basic blocks.

I was going through the documentation and found that indirect branch are
produced by virtual function calls. Are there any other cases which result
into CodeGen procuding Indirect Branch?

On Thu, Jul 24, 2008 at 12:06 PM, David Greene <dag at cray.com> wrote:

> On Thursday 24 July 2008 01:47, Chris Lattner wrote:
> > On Jul 23, 2008, at 8:47 PM, kapil anand wrote:
> > > Specifically, I need a way to represent indirect branch instruction
> > > (in binary) as an equivalent LLVM instruction. With switch
> > > instruction , I would have to list all the possible targets and then
> > > initialize the corresponding instruction. I was just thinking
> > > whether it might be possible to have some kind of indirect branch
> > > where label is a "variable" and not an explicit label present in
> > > module.
> >
> > No, and there never will be a way.  In the future, we will probably
> > extend the CFG to better model the GCC "address of label + indirect
> > goto" extension.  However, even with that, all the possible
> > destinations of an indirect goto must be explicitly known.
>
> This would also help with Fortran assigned gotos.
>
>                                              -Dave
>  _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080724/a19a5d22/attachment.html>


More information about the llvm-dev mailing list