Thanks for the fast reply. I'll do as you suggested, and create my own identity instructions with "add" for int's and "getelementptr" for pointers. , Tobias On Thu, 17 Jun 2004, Misha Brukman wrote:> On Thu, Jun 17, 2004 at 05:09:30PM +0200, Tobias Nurmiranta wrote: > > A small thing I miss in the intermediate representation is a simple > > assignment instruction, like: > > > > %x = uint 3 > > or: > > %x = uint %y > > > > It would simplify the implementation of frontends, I think. > > Neither of these is necessary, and adding new instructions means every > transformation has to handle these (extra cases, extra complexity, etc.) > > In the first case, "x = 3", you can simply constant-propagate the 3 and > use it everywhere you would use the x. If you are programming an LLVM > pass, create a Value* that is the "uint 3" and use it. If you are > writing LLVM assembly by hand, use "x = add uint 3, 0" and you have the > same effect, without an extra special case for future transformations. > > As for "x = y", same as above: since we are using SSA, y cannot be > assigned a new value, ever, so you can just use y anywhere below where > you would otherwise use x, and the assignment isn't even necessary. > > Basically, the point is to have an orthogonal instruction set where > little (or no) functionality is duplicated across the instructions, > because that cuts down on the number of cases a transformation has to > deal with. > > -- > Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Thu, 17 Jun 2004, Tobias Nurmiranta wrote:> > Thanks for the fast reply. I'll do as you suggested, and create my own > identity instructions with "add" for int's and "getelementptr" for > pointers.Another thing to point out is that this might only be happening because your front-end is attempting to generate SSA. In general, we don't recommend that front-ends bother with generating code in SSA form: it's needless effort and duplicates functionality in the optimizer. In particular, consider making all user variables into stack memory objects with the alloca instruction. If you do this, copies are simply loads and stores to memory, which don't require any special handling: in: int X = 4; ... X = 5; ... = X %X = alloca int ;; in the entry bb for the function ... store int 4, int* %X ... store int 5, int* %X ... ... = load int* %X This makes it really easy for a front-end to generate code, doesn't have problems with copies, and the optimizer will construct SSA (and nice clean code) for you. :) -Chris> On Thu, 17 Jun 2004, Misha Brukman wrote: > > On Thu, Jun 17, 2004 at 05:09:30PM +0200, Tobias Nurmiranta wrote: > > > A small thing I miss in the intermediate representation is a simple > > > assignment instruction, like: > > > > > > %x = uint 3 > > > or: > > > %x = uint %y > > > > > > It would simplify the implementation of frontends, I think. > > > > Neither of these is necessary, and adding new instructions means every > > transformation has to handle these (extra cases, extra complexity, etc.) > > > > In the first case, "x = 3", you can simply constant-propagate the 3 and > > use it everywhere you would use the x. If you are programming an LLVM > > pass, create a Value* that is the "uint 3" and use it. If you are > > writing LLVM assembly by hand, use "x = add uint 3, 0" and you have the > > same effect, without an extra special case for future transformations. > > > > As for "x = y", same as above: since we are using SSA, y cannot be > > assigned a new value, ever, so you can just use y anywhere below where > > you would otherwise use x, and the assignment isn't even necessary. > > > > Basically, the point is to have an orthogonal instruction set where > > little (or no) functionality is duplicated across the instructions, > > because that cuts down on the number of cases a transformation has to > > deal with. > > > > -- > > Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/
Hi again, Which optimization/flag to "opt" should I use to optimize away these alloca's? In most cases it is more convenient for me to use SSA-registers, but for example if-statements and some others, it is nicer to use alloca. Thanks for the advice. , Tobias On Thu, 17 Jun 2004, Chris Lattner wrote:> On Thu, 17 Jun 2004, Tobias Nurmiranta wrote: > > > > Thanks for the fast reply. I'll do as you suggested, and create my own > > identity instructions with "add" for int's and "getelementptr" for > > pointers. > > Another thing to point out is that this might only be happening because > your front-end is attempting to generate SSA. In general, we don't > recommend that front-ends bother with generating code in SSA form: it's > needless effort and duplicates functionality in the optimizer. > > In particular, consider making all user variables into stack memory > objects with the alloca instruction. If you do this, copies are simply > loads and stores to memory, which don't require any special handling: > > in: > > int X = 4; > ... > X = 5; > ... > = X > > %X = alloca int ;; in the entry bb for the function > ... > store int 4, int* %X > ... > store int 5, int* %X > ... > ... = load int* %X > > This makes it really easy for a front-end to generate code, doesn't have > problems with copies, and the optimizer will construct SSA (and nice clean > code) for you. :) > > -Chris