nkavv at physics.auth.gr
2007-Oct-05 11:23 UTC
[LLVMdev] Supporting pre-allocated registers in LLVM
> > 1. I can see the standard algorithms (bigblock, linearscan -- good > > choice for > > the JIT and for general use as well, and the other algorithms). Is > > it possible > > to pre-allocate registers in your linearscan (or in another > > allocation engine) > > for specific source-level or (better) intermediate code (bitcode) > > level > > variables? > > Yes that's done at instruction selection time. If you specify an > instruction definition must go to a physical register, the selector > and scheduler will take care of it. Same for instructions that require > its operands that must be in fixed registers.You mean a temporary defined in an instruction. OK, that is what i basically need here. Is it guaranteed to "live" in the physical register for the entire program (or at least for a single function, which would trivially work for single-function programs)?> > 2. Which are the new register allocation algorithms currently under > > design? Do > > they support preallocation of registers (it is different to "fixing" > > a register > > in GCC parlance)? > > I know of a number of allocators in development. They are not yet made > available to the public yet. Perhaps their authors can chime in.Fernando has a lot of work going on, and his UCLA page looks very interesting. Fernando, is your SSA-based regalloc usable as of now; is it in an SVN repo? Further, do you allow register "fixing" (in the sense of pre-allocated a register for its entire lifetime, or for the entire program)? Kind regards Nikolaos Kavvadias
On Oct 5, 2007, at 4:23 AM, nkavv at physics.auth.gr wrote:> >>> 1. I can see the standard algorithms (bigblock, linearscan -- good >>> choice for >>> the JIT and for general use as well, and the other algorithms). Is >>> it possible >>> to pre-allocate registers in your linearscan (or in another >>> allocation engine) >>> for specific source-level or (better) intermediate code (bitcode) >>> level >>> variables? >> >> Yes that's done at instruction selection time. If you specify an >> instruction definition must go to a physical register, the selector >> and scheduler will take care of it. Same for instructions that >> require >> its operands that must be in fixed registers. > > You mean a temporary defined in an instruction. OK, that is what i > basically > need here. Is it guaranteed to "live" in the physical register for > the entire > program (or at least for a single function, which would trivially > work for > single-function programs)?No it's just guaranteed to be defined in a fixed register. The allocator is free to copy it to another register, spill it to stack. It all depends on proximity of uses and overall register pressure. Evan> > >>> 2. Which are the new register allocation algorithms currently under >>> design? Do >>> they support preallocation of registers (it is different to "fixing" >>> a register >>> in GCC parlance)? >> >> I know of a number of allocators in development. They are not yet >> made >> available to the public yet. Perhaps their authors can chime in. > > Fernando has a lot of work going on, and his UCLA page looks very > interesting. > Fernando, is your SSA-based regalloc usable as of now; is it in an > SVN repo? > Further, do you allow register "fixing" (in the sense of pre- > allocated a > register for its entire lifetime, or for the entire program)? > > > Kind regards > Nikolaos Kavvadias > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev