[ sorry for the late reply ] Patrick Meredith <pmeredit at uiuc.edu> wrote:> All register uses are SSA. Memory is not in SSA. The mem2reg pass > which promotes stack variables to registers effectively converts non- > SSA to SSA. There was a reg2mem pass, written by Andrew Lenharth, I'm > not sure if it's still being maintained.What is the difference between register and memory? I don't see such distinction in the LRM. Do you mean for example register = i32 memory = i32* ? Thanks,> On Jul 7, 2008, at 8:47 AM, Matthieu Moy wrote: > > > Hi, > > > > Silly question from an LLVM newbie: the LLVM LRM say that the bytecode > > is "is an SSA based representation". Indeed, my experience with > > llvm-gcc is that the generated code is not necessarily SSA, while > > the one given by "llvm-gcc -O1" is. > > > > Is this assumption correct? > > > > Is there a non-SSA to SSA translator available? > > > > Thanks,-- Matthieu
Memory is what the i32* points too. The i32* itself is in a register. You can store to it as many times as you want, but you can't change the address, because that would violate SSA. On Jul 17, 2008, at 4:26 AM, Matthieu Moy wrote:> [ sorry for the late reply ] > > Patrick Meredith <pmeredit at uiuc.edu> wrote: >> All register uses are SSA. Memory is not in SSA. The mem2reg pass >> which promotes stack variables to registers effectively converts non- >> SSA to SSA. There was a reg2mem pass, written by Andrew Lenharth, >> I'm >> not sure if it's still being maintained. > > What is the difference between register and memory? I don't see such > distinction in the LRM. > > Do you mean for example > > register = i32 > memory = i32* > > ? > > Thanks, > >> On Jul 7, 2008, at 8:47 AM, Matthieu Moy wrote: >> >>> Hi, >>> >>> Silly question from an LLVM newbie: the LLVM LRM say that the >>> bytecode >>> is "is an SSA based representation". Indeed, my experience with >>> llvm-gcc is that the generated code is not necessarily SSA, while >>> the one given by "llvm-gcc -O1" is. >>> >>> Is this assumption correct? >>> >>> Is there a non-SSA to SSA translator available? >>> >>> Thanks, > > -- > Matthieu > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Patrick Meredith <pmeredit at uiuc.edu> writes:> Memory is what the i32* points too. The i32* itself is in a > register. You can store to it as many times as you want, but you > can't change the address, because that would violate SSA.Thanks, For the record, I finally understood by making a few experiments: This is (obviously) valid: define i32 @main() { %some-variable = add i32 1, 1 ; integer with the value 1+1 %some-other-variable = add i32 %some-variable, 1 ret i32 %some-other-variable } This is not (the assembler complains with ``Redefinition of value 'some-variable' of type 'i32' ''): define i32 @main() { %some-variable = add i32 1, 1 ; integer with the value 1+1 %some-variable = add i32 %some-variable, 1 ret i32 %some-variable } but this one is: define i32 @main() { %some-pointer = alloca i32 ; declares an int in memory (stack) store i32 42, i32* %some-pointer store i32 54, i32* %some-pointer %retval = load i32* %some-pointer ret i32 %retval } In short, "Single Assignment" means "Single '='", not "Single 'store'". -- Matthieu
Hi Matthieu> What is the difference between register and memory? I don't see such > distinction in the LRM. > > Do you mean for example > > register = i32 > memory = i32*Not really. Registers are all values that have a name starting with % and are by definition local to a function. These are in SSA form, so you can't assign them twice (instead, you would simply use a new register, since you have infinite of them). The result of an instruction is always stored to a register. Memory, on the other hand, cannot be accessed directly and has to be explicitely allocated. The only way to access memory is to obtain a pointer to it (Usually in a register) and execute a load or a store instruction. For example, the following C code: int run(){ int i = foo(); i += 1; return i; } will be initially mapped to have every local variable in memory, since that does not require complicated stuff to comply with SSA (which only gets interesting when the code is more complicated). So, %i = alloca i32, align 4 ; <i32*> [#uses=4] %call = call i32 (...)* @foo( ) ; <i32> [#uses=1] store i32 %call, i32* %i %tmp = load i32* %i ; <i32> [#uses=1] %add = add i32 %tmp, 1 ; <i32> [#uses=1] store i32 %add, i32* %i %tmp1 = load i32* %i ; <i32> [#uses=1] ret i32 %tmp1 Here you can see that the variable i is allocated in memory, allocated by the first alloca instruction. There, %i contains the _address_ of i, not its value. Note that %i is again a register and is in SSA form. To get at its value, load and store instructions are used. For every intermediate value (ie, evaluated expressions), registers are used (%call, %tmp, %add, %tmp1). However, the above code is not very efficiently mappable on a regular processor, since accessing memory all the time is not necessary. We can use the "mem2reg" optimization pass, which reduces the above to: %call = call i32 (...)* @foo( ) ; <i32> [#uses=1] %add = add i32 %call, 1 ; <i32> [#uses=1] ret i32 %add Now, no memory is involved and all values are in SSA. This code is a lot easier for a codegen to map, since the lifetimes of various values are a lot shorter and dataflow is clearer. Hope that this helps a bit? Also, did you see http://www.llvm.org/docs/tutorial/LangImpl7.html already? Gr. Matthijs -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080717/445a18e7/attachment.sig>