similar to: [LLVMdev] where are my phi-nodes?

Hi Maarten, If you look at the start of basic block 2 (bb2) you'll see the following instruction: %a_addr.0 = phi i32 [ 1, %bb ], [ 0, %bb1 ] ; <i32> [#uses=1] This is an SSA phi node which assigns a value of either 1 or 0 to %a_addr.0 depending on whether control reached the PHI node from basic block bb, or bb1. - Lang. On Thu, Sep 23, 2010 at 11:26 PM, maarten faddegon <

Hi, I am studying SSA and some time ago I asked on this list how to see the phi nodes in the llvm ir output. I learned then to use this command: opt -mem2reg test.ll -S > test_mem2reg.ll However, if you look at the output (attached to this message) there is something I do not understand. At the end of the function @f at line 18, the function returns the variable %a_addr.0. However, this

Hi Maarten, > I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". Attached to this > message are the source and the resulting ll output. compile with optimization. The llvm-gcc front-end "cheats" and stores/loads all values to/from memory, avoiding the need to construct phi nodes; instead it lets the optimizers do that. For what it's worth the dragonegg

On Sep 13, 2010, at 1:15 AM, Duncan Sands wrote: >> I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". Attached to this >> message are the source and the resulting ll output. > > compile with optimization. The llvm-gcc front-end "cheats" and stores/loads all > values to/from memory, avoiding the need to construct phi nodes; instead it lets >

On Sep 13, 2010, at 10:46 AM, John McCall wrote: > On Sep 13, 2010, at 1:15 AM, Duncan Sands wrote: >>> I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". >>> Attached to this >>> message are the source and the resulting ll output. >> >> compile with optimization. The llvm-gcc front-end "cheats" and >> stores/loads

Hi, Paul Curtis wrote: > If you read the Arm Architecture document for ARMv5, it states for MUL: > > "Operand restriction: Specifying the same register for <Rd> and <Rm> was > previously described as producing UNPREDICTABLE results. There is no > restriction in ARMv6, and it is believed all relevant ARMv4 and ARMv5 > implementations do not require this

Hi All, I try to build a cross-compiler that compiles for powerpc but runs on my pentium. As a base I used the arm cross-compiler script but changed: CROSS_HOST="x86_64-unknown-linux-gnu" CROSS_TARGET="powerpc-linux" CROSS_MARCH="750" LLVM is building ok, but the second step: building llvm-gcc fails with a rather strange error which I appended to the end of this

I try to build a cross powerpc compiler, but llvm-gcc fails. Eric Christopher wrote: > Looks like you don't have an assembler for your target installed that > llvm-gcc can find. I have binutils installed for powerpc and verified they are working with a simple hello world program. $ powerpc-750-linux-gnu-as --version GNU assembler 2.16.1 However, the xgcc build during the seems to

On Sep 13, 2010, at 10:58 AM, Fariborz Jahanian wrote: > On Sep 13, 2010, at 10:46 AM, John McCall wrote: >> On Sep 13, 2010, at 1:15 AM, Duncan Sands wrote: >>>> I compiled with "llvm-gcc -emit-llvm test.c -S -o test.ll". Attached to this >>>> message are the source and the resulting ll output. >>> >>> compile with optimization. The

Hi, I am using a cross compiler to compiler for the arm5 architecture. For this architecture it is not allowed that a destination register is also used as source register. In 2007 a patch was discussed at the mailing list, however my compiler still is producing this result. Does anyone know if this patch is actually applied? * I use the following arguments: llvm-gcc -mfpu=vfp -mlittle-endian

I have a few pass managers, but only one of them has been initialized with addPassesToEmitCode, how do I find how many passes are added to a function pass manager ? Thank you, Xin On Fri, May 20, 2011 at 1:00 PM, <llvmdev-request at cs.uiuc.edu> wrote: > Send LLVMdev mailing list submissions to > llvmdev at cs.uiuc.edu > > To subscribe or unsubscribe via the World Wide

Hi Thanks for your answers so far. I am currently stumbling into new questions. Naive as i am, i thought that the llvm-bytecode is allways in SSA form. But this doesn't seem to be the case. At least there are no phi instructions embedded if the bytecode drops out of llvm-gcc? Looking into the archives this has been discussed before:

Misha Brukman wrote: > LLVM Machine code is in SSA. This explains quite a lot. I though it's possible to just reduce convert phis into copy instructions in predecessors -- all of which will have the same destination register. > gets you two definitions of r. So we have machine PHI nodes merge the > two possible values into one for result of r. These phis get removed > after

> I try to build a cross powerpc compiler, but llvm-gcc fails on > crtstuff.c / crtbegin.o In the archives I found a thread where more or less the same problem is discussed: http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-January/037327.html Can I conclude from this that indeed llvm-gcc for powerpc-linux is broken? Is anyone maintaining llvm-gcc for powerpc-linux or is it abandoned?

On Fri, 9 Jul 2004, Vladimir Prus wrote: > Misha Brukman wrote: > > > LLVM Machine code is in SSA. > > This explains quite a lot. I though it's possible to just reduce convert phis > into copy instructions in predecessors -- all of which will have the same > destination register. There are algorithms for eliminating PHI nodes, but they aren't quite so simple.

Somewhere during optimization PHI nodes on pointer types (including alloca instructions) are being introduced, and they persist through the scalar replacement of aggregates pass and others. I can't seem to find a combination of passes or transformations to get rid of them. Has anyone had this problem before, and know a transformation to eliminate it? My optimization passes rely on

Hi, LLVMers. I am trying to restore the original HL code from LLVM IR (kinda reverse engineering). However, I have no good idea about how to handle PHI nodes. It is quite tricky for me to deal with the PHI nodes in LLVM IR in order to restore the original-like code. I read some reverse engineering thesis but they are a little bit old so don't handle SSA form. Could you shed some lights on

Hi Andrew, > Somewhere during optimization PHI nodes on pointer types (including > alloca instructions) are being introduced, and they persist through the > scalar replacement of aggregates pass and others. I can't seem to find > a combination of passes or transformations to get rid of them. Has > anyone had this problem before, and know a transformation to eliminate > it?

On 08/20/2012 03:46 PM, Duncan Sands wrote: > Hi Andrew, > >> Somewhere during optimization PHI nodes on pointer types (including >> alloca instructions) are being introduced, and they persist through the >> scalar replacement of aggregates pass and others. I can't seem to find >> a combination of passes or transformations to get rid of them. Has >> anyone

I have a basic question concerning how LLVM assigns labels to the LHS of an SSA assignment. My impression from the interface is you can pick a string which becomes the label for the result. However if you multiple labels which share the same name in a function a number gets added to the end of the label (is this correct?). In cases where you need to know what these resulting labels are is it