search for: x_addr

Hello everyone, I'm currently constructing a graph from LLVM bitcode, and I have a question about accessing the names of the variables shown in the .ll assembly file, assuming it's possible... For example, with %2 = load i32* %x_addr, align 4 ; <i32> [#uses=1] I can retrieve the opcodeName() from the Instruction object, which is "load". I can also access the operand and use getName() to retrieve "x_addr". However, this instruction is storing into %2 - how do I access the name of that? Also, when an...

...s Stanier wrote: > Hello everyone, > > I'm currently constructing a graph from LLVM bitcode, and I have a question > about accessing the names of the variables shown in the .ll assembly file, > assuming it's possible... > > For example, with > > %2 = load i32* %x_addr, align 4 ; <i32> [#uses=1] > > I can retrieve the opcodeName() from the Instruction object, which is > "load". I can also access the operand and use getName() to retrieve > "x_addr". However, this instruction is storing into %2 - how do I access the > name...

...internal constant [18 x i8] c"#<unknown 0x%08x>\00" ; <[18 x i8]*> [#uses=1] @"\01LC7" = internal constant [45 x i8] c"evaluation halted with error: %d and value: \00" ; <[45 x i8]*> [#uses=1] define void @print_val(i32 %x) nounwind { entry: %x_addr = alloca i32 ; <i32*> [#uses=10] %"alloca point" = bitcast i32 0 to i32 ; <i32> [#uses=0] store i32 %x, i32* %x_addr %0 = load i32* %x_addr, align 4 ; <i32> [#uses=1] %1 = and i32 %0, 3 ; <i32> [#uses=1] %2 = icmp eq i32 %1, 0 ; <i1> [#uses=1] br i...

I'm trying to generate the equivalent of this function dynamically in llvm (a la http://llvm.org/docs/tutorial/JITTutorial1.html) but after half a day of searching I still haven't found how to create the equivalent of the & (address of) operator in the llvm API, more exactly how do I obtain the i8* from the i32 below void fn(int x) { another_fn(&x); } thanks for any

....uk> wrote: > > Hello everyone, > > I'm currently constructing a graph from LLVM bitcode, and I have a question > about accessing the names of the variables shown in the .ll assembly file, > assuming it's possible... > > For example, with > > %2 = load i32* %x_addr, align 4         ; <i32> [#uses=1] > > I can retrieve the opcodeName() from the Instruction object, which is > "load". I can also access the operand and use getName() to retrieve > "x_addr". However, this instruction is storing into %2 - how do I access the &gt...

...%y, float* %result) nounwind optsize { entry: %.not7 = fcmp une float %x, 0.000000e+00 ; <i1> [#uses=1] %0 = fcmp une float %y, 0.000000e+00 ; <i1> [#uses=2] %or.cond8 = and i1 %.not7, %0 ; <i1> [#uses=1] br i1 %or.cond8, label %bb, label %bb4 bb: ; preds = %bb, %entry %x_addr.06 = phi float [ %x, %entry ], [ %3, %bb ] ; <float> [#uses=2] %z.05 = phi float [ 0.000000e+00, %entry ], [ %2, %bb ] ; <float> [#uses=1] %1 = mul float %x_addr.06, %y ; <float> [#uses=1] %2 = add float %z.05, %1 ; <float> [#uses=2] %3 = add float %x_addr.06, 1.0000...

Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful

LLVM seems to be generating way too complex of branching based on the short-circuit optimization. The code in question is as follows: define void @ test_fc_while_and(float %x, float %y, float addrspace(11)* %result) nounwind { entry: %tobool3 = fcmp une float %x, 0.000000e+000 ; <i1> [#uses=1] %tobool24 = fcmp une float %y, 0.000000e+000 ;

...e of reg16385 in the following MachineInstr. I know now in the llvm bitcode, the type of a Instruction could be obtained from the Value::GetType(), but what is the counterpart in MachineInstr (not derived from class Value)? %reg16385<def> = MOV32rm <fi#0>, 1, %reg0, 0, %reg0; mem:LD4[%x_addr] GR32:%reg16385 -- Best regards, Li Qingan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110129/9cb9b514/attachment.html>

...s well: For example consider this snippet: call void @llvm.dbg.declare({ }* %i2, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable13 to { }*)) call void @llvm.dbg.stoppoint(i32 11, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) %0 = load %struct.test** %x_addr, align 8 ; <%struct.test*> [#uses=1] %1 = getelementptr %struct.test* %0, i32 0, i32 0 ; <[10 x i8]*> [#uses=1] %2 = getelementptr [10 x i8]* %1, i32 0, i64 10 ; <i8*> [#uses=1] %2 is pretty-printed as: variable x.buffer[10] (in gep-struct-field-overflow.c:8)...

...ssembly: define i32 @ilog2(i32 %x) { entry: %tmp718 = icmp eq i32 %x, 0 ; <i1> [#uses=1] br i1 %tmp718, label %bb9, label %bb5 bb5: ; preds = %bb5, %entry %indvar = phi i32 [ 0, %entry ], [ %indvar.next, %bb5 ] ; <i32> [#uses=2] %x_addr.015.0 = phi i32 [ %x, %entry ], [ %tmp2, %bb5 ] ; <i32> [#uses=2] %tmp2 = ashr i32 %x_addr.015.0, 1 ; <i32> [#uses=1] %tmp7 = icmp ult i32 %x_addr.015.0, 2 ; <i1> [#uses=1] %indvar.next = add i32 %indvar, 1 ; <i32&g...

...<g0>}}"]; Node0xe1f4d0 [shape=record,shape=Mrecord,label="{ i32*: SMR\n|{<g0>|<g1>}}"]; Node0xe1f4d0:g0 -> Node0xe1f3a0; Node0xe20900 [shape=record,shape=Mrecord,label="{ i32: GR\n @global\n|{<g0>}}"]; Node0xe16530[ label =" %x_addr"]; Node0xe16530 -> Node0xe1f4d0[arrowtail=tee,color=gray63]; Node0xe162f0[ label =" %x"]; Node0xe162f0 -> Node0xe1f3a0[arrowtail=tee,color=gray63]; Node0xe16950[ label =" %tmp4"]; Node0xe16950 -> Node0xe1f3a0[arrowtail=tee,color=gray63]; N...

...;. If you have code like "char *x = malloc(sizeof(int));" you're going to get different LLVM bytecode depending on what platform your llvm-gcc is set to. LLVM is portable in the sense that the bytecode will behave the same way on every platform. So if the above code becomes "%x_addr = malloc i32" then you get a 32-bit integer regardless of the abilities of the underlying system. Finally, the C backend's output isn't portable in the sense that it uses GCC extensions to get the correct output. Which is fine so long as you're compiling its output with GCC....

...> Node0xe1f4d0 [shape=record,shape=Mrecord,label="{ i32*: SMR\n|{<g0>|<g1>}}"]; > Node0xe1f4d0:g0 -> Node0xe1f3a0; > Node0xe20900 [shape=record,shape=Mrecord,label="{ i32: GR\n @global\n|{<g0>}}"]; > Node0xe16530[ label =" %x_addr"]; > Node0xe16530 -> Node0xe1f4d0[arrowtail=tee,color=gray63]; > Node0xe162f0[ label =" %x"]; > Node0xe162f0 -> Node0xe1f3a0[arrowtail=tee,color=gray63]; > Node0xe16950[ label =" %tmp4"]; > Node0xe16950 -> Node0xe1f3a0[arrowtail...

...hape=record,shape=Mrecord,label="{ i32*: > SMR\n|{<g0>|<g1>}}"]; > > Node0xe1f4d0:g0 -> Node0xe1f3a0; > > Node0xe20900 [shape=record,shape=Mrecord,label="{ i32: GR\n > @global\n|{<g0>}}"]; > > Node0xe16530[ label =" %x_addr"]; > > Node0xe16530 -> Node0xe1f4d0[arrowtail=tee,color=gray63]; > > Node0xe162f0[ label =" %x"]; > > Node0xe162f0 -> Node0xe1f3a0[arrowtail=tee,color=gray63]; > > Node0xe16950[ label =" %tmp4"]; > > Node0xe16950 -&g...

Hi, I'm interested in whether or not there is a way of providing source-level annotations to help LLVM with optimizations, similar to VisualC++'s __assume facility (http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx). As part of our PHP compiler (phpcompiler.org), it would be great to be able to annotate our generated C code with, for example, (var != NULL), or (var->type ==

For my master's thesis, I am trying to cross compile programs for the PSP (PlayStation Portable) with LLVM and llvm-gcc. This is what I do: (1) compile a program and the libraries it uses (libpng etc.) with llvm-gcc (2) link the bitcode files with llvm-ld into one file (3) run "llc -march=c" on the result (4) compile the resulting C source with the PSP toolchain It seems to work

...de0xe1f4d0 [shape=record,shape=Mrecord,label="{ i32*: SMR\n|{<g0>|<g1>}}"]; >> Node0xe1f4d0:g0 -> Node0xe1f3a0; >> Node0xe20900 [shape=record,shape=Mrecord,label="{ i32: GR\n @global\n|{<g0>}}"]; >> Node0xe16530[ label =" %x_addr"]; >> Node0xe16530 -> Node0xe1f4d0[arrowtail=tee,color=gray63]; >> Node0xe162f0[ label =" %x"]; >> Node0xe162f0 -> Node0xe1f3a0[arrowtail=tee,color=gray63]; >> Node0xe16950[ label =" %tmp4"]; >> Node0xe16950 -> No...

On Oct 10, 2008, at 1:43 PM, John Criswell wrote: > Dear All, > > Are there a set of libraries for easily manipulating the LLVM debug > information? For example, given an Instruction *, is there an > interface > that will find the nearest llvm.dbg.stoppoint(), or given an alloca, > is > there an interface for getting its source level information by tracing > it to

Dear All, Are there a set of libraries for easily manipulating the LLVM debug information? For example, given an Instruction *, is there an interface that will find the nearest llvm.dbg.stoppoint(), or given an alloca, is there an interface for getting its source level information by tracing it to a llvm.dbg.declare()? As far as I know, no such utility interfaces exist. While I can role my