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. -Kapil On Wed, Jul 23, 2008 at 10:36 PM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Wed, Jul 23, 2008 at 5:57 PM, kapil anand <kapilanand2 at gmail.com> > wrote: > > Hi, > > > > I was thinking about the ways to represent indirect branch in LLVM. It > seems > > that "Switch instruction" is the only way to logically represent indirect > > branch inside LLVM. > > Is there any other easier way to represent indirect branch in LLVM? > > Yeah, that's essentially it; the only forms of control flow LLVM > supports are branches/switches, calls, and exceptions. There's been > some discussion that this makes it difficult to represent some > constructs, like setjmp/longjmp and the gcc goto from nested function > extension, but nobody has really proposed anything yet. > > LLVM supports turning functions with the fastcc calling convention > into tail calls; that can be useful in some cases. Is there something > in particular you're running into issues with? > > -Eli > _______________________________________________ > 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/20080723/3f56534f/attachment.html>
On Wed, Jul 23, 2008 at 8:47 PM, kapil anand <kapilanand2 at gmail.com> 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.Oh... I think you're stuck with either a massive switch statement or tail calls. -Eli
Just to make sure, can the label in a branch instruction be a "variable"? On Thu, Jul 24, 2008 at 12:08 AM, Eli Friedman <eli.friedman at gmail.com> wrote:> On Wed, Jul 23, 2008 at 8:47 PM, kapil anand <kapilanand2 at gmail.com> > 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. > > Oh... I think you're stuck with either a massive switch statement or tail > calls. > > -Eli > _______________________________________________ > 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/a2201505/attachment.html>
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. Without knowing the CFG, the compiler cannot do any useful optimization. Eli is right, you probably want lots of tail calls or something. -Chris
So, that means that &&(Label) operator, which is defined in C++, is also
not
supported currently in LLVM. I thought I could obtain address of basic block
indirectly through this small hack but it does not seem to work.
Actually, I tried to make folloing dummy C++ code which uses this operator:
*int main(int argc,char** argv)
{
int x;
int y;
L1: printf("Hello\n");
L2: printf("World\n");*
* if(atoi(argv[1]) == 1)
x = &&L1;
else*
* x = &&L2;*
* y = x + 10;
return y;
}*
*
* *( The above code is not correct as we cast from pointer to interger and
also not an example of good programming but would anyways compile correctly
in GCC)*
If I use llvmgcc, I get:
@.str = internal constant [6 x i8] c"Hello\00"
@.str1 = internal constant [6 x i8] c"World\00"
*define i32 @main(i32 %argc, i8** %argv) nounwind {
entry: %"alloca point" = bitcast i32 0 to i32
br label %L1*
*L1: ; preds = %indirectgoto, %indirectgoto, %entry
%tmp1 = call i32 @puts( i8* getelementptr ([6 x i8]* @.str, i32 0,
i32
br label %L2*
*L2: ; preds = %indirectgoto, %L1
%tmp2 = call i32 @puts( i8* getelementptr ([6 x i8]* @.str1, i32 0,
i32
%tmp4 = getelementptr i8** %argv, i32 1
%tmp5 = load i8** %tmp4, align 4
%tmp6 = call i32 @atoi( i8* %tmp5 ) nounwind
%tmp7 = icmp eq i32 %tmp6, 1
%tmp78 = zext i1 %tmp7 to i8
%toBool = icmp ne i8 %tmp78, 0
br i1 %toBool, label %bb, label %bb9
bb: ; preds = %L2
ptrtoint i8* inttoptr (i32 1 to i8*) to i32
br label %bb10*
*bb9: ; preds = %L2
ptrtoint i8* inttoptr (i32 2 to i8*) to i32
br label %bb10
bb10: ; preds = %bb9, %bb
%x.0 = phi i32 [ 2, %bb9 ], [ 1, %bb ]
%tmp12 = add i32 %x.0, 10
br label %return
return:
ret i32 %tmp12*
**
*indirectgoto: ; No predecessors!
switch i32 undef, label %L1 [
i32 1, label %L1
i32 2, label %L2
]
}*
*declare i32 @puts(i8*)*
*declare i32 @atoi(i8*)
*
**
The instruction marked in BOLD should correspond to each other but LLVM code
does not seem to capture the logic represented in corresponding C Code. So,
should we take care to avoid such kind of label operators in code.
Kapil
On Thu, Jul 24, 2008 at 2:47 AM, Chris Lattner <clattner at apple.com>
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.
>
> Without knowing the CFG, the compiler cannot do any useful
> optimization. Eli is right, you probably want lots of tail calls or
> something.
>
> -Chris
> _______________________________________________
> 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/828a6ae4/attachment.html>
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