similar to: [LLVMdev] uses of unwind lead to crashes

James 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

On Wed, Oct 1, 2008 at 1:19 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > 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

The other repliers have been right that you probably want to use Value*s rather than string names in constructing your dependency graph, but I wanted to clear up a second possible point of confusion. When you see %2 in the assembly, that's an indication that the instruction's name is empty. That is, value->getName() == "". As far as I know, llvm-dis just generates numbers in

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

Hi, I'm trying to write up my little m68k backend things have been going smoothly. I've been working with the x86 backend as a template, fixing things as I go. Now I've run into branches and I have a crash I don't really understand. Here's the sample IR I'm running llc on to generate assembly: define i32 @ilog2(i32 %x) { entry: %tmp718 = icmp eq i32 %x, 0

Hi, I want to know what is the type or size of a virtual register in a Machineinstr::MachineOperand (If this MachineOperand is a register). For example, what is the size 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)?

On 2008-10-11 00:34, Evan Cheng wrote: > 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

Hi, all: Recently I am debugging the DSA and want to learn how it work, and now I am checking the local datastructure analysis. I use the following command to print the graph: (gdb) p g.dump() digraph DataStructures { label="Function addG"; Node0xe1f3a0 [shape=record,shape=Mrecord,label="{ i32: MRE\n|{<g0>}}"]; Node0xe1f4d0

Kevin André wrote: > 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

Dear Tianwei, You can use the -analyze option to the opt tool to tell the DSA passes to store their results in files. When you use the -analyze option, the DSA passes will create a separate file for each function (and possible one file to hold the globals graph). For this reason, I recommend running opt in a special empty directory because DSA will generate *a lot* of files. Second, to

Tianwei wrote: > On Wed, Apr 23, 2008 at 11:59 PM, John Criswell <criswell at cs.uiuc.edu<mailto:criswell at cs.uiuc.edu>> wrote: > Dear Tianwei, > > You can use the -analyze option to the opt tool to tell the DSA passes > to store their results in files. When you use the -analyze option, the > DSA passes will create a separate file for each function (and possible

On Wed, Apr 23, 2008 at 11:59 PM, John Criswell <criswell at cs.uiuc.edu> wrote: > Dear Tianwei, > > You can use the -analyze option to the opt tool to tell the DSA passes > to store their results in files. When you use the -analyze option, the > DSA passes will create a separate file for each function (and possible > one file to hold the globals graph). For this reason,

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

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 ;

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

That definitely looks like a bug, but not one that anyone will be eager to fix. It's very old code that tried to be clever, and that's the hardest kind of code to fix. Remember Kernighan's Law: "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you?re as clever as you can be when you write it, how will you ever debug it?"

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