search for: firstvirtualregister

On 01/07/2011 02:07 AM, Chris Lattner wrote: > > Unless your goal is to merge this work onto LLVM mainline, the best thing to do is a local hack in your tree. > > -Chris Yes, I will create a patch for my tree to increase FirstVirtualRegister. Would this be a good change to include in 2.9?

We might want to make physical registers negative and virtuals positive, or vice versa. Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes. Since 0 is used all over the place as "invalid register" it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. t...

On Jan 7, 2011, at 11:25 AM, Dale Johannesen wrote: > We might want to make physical registers negative and virtuals positive, or vice versa. Then FirstVirtualRegister is 0 or 1, and we could get rid of those annoying subtractions of FirstVirtualRegister all over the virtual-register-handling passes. Since 0 is used all over the place as "invalid register" it is probably best to leave this alone, let FirstVirtualRegister be 1, and simply ignore (i.e. t...

Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister to something quite a bit larger - such as 2^31? I'm working on a target where all SSA values need to be assigned physical registers, and the current limit of 16384 may limit the size of programs that I'm able to handle. 2^31 is a nice value since there are equal numbers of possible physic...

...ARM). I'm going to revert it for now until it has been addressed. > > Probably caused by this member: > > /// KillIndices - The index of the most recent kill (proceding bottom-up), > /// or ~0u if the register is not live. > unsigned KillIndices[TargetRegisterInfo::FirstVirtualRegister]; > > And this: > > std::fill(KillIndices, array_endof(KillIndices), ~0u); > > It should probably be dynamically allocated with TRI->getNumRegs() members instead. Yep. David Goodwin is going to fix it. Evan > > /jakob >

...was this trivial patch: Index: include/llvm/Target/TargetRegisterInfo.h =================================================================== --- include/llvm/Target/TargetRegisterInfo.h (revision 89468) +++ include/llvm/Target/TargetRegisterInfo.h (working copy) @@ -299,8 +299,8 @@ /// FirstVirtualRegister - This is the first register number that is /// considered to be a 'virtual' register, which is part of the SSA /// namespace. This must be the same for all targets, which means that each - /// target is limited to 1024 registers. - FirstVirtualRegister = 1024 + /// ta...

...iveIntervals to build the interference graph, Ok. > because LiveVariables do not provide an interface to iterate through > all viritual registers. Ok, you could add a method to LiveVariables that returns VirtRegInfo.size(). The virtual registers are defined by the range: [MRegisterInfo::FirstVirtualRegister, MRegisterInfo::FirstVirtualRegister+VirtRegInfo.size()] Alternatively, the same information can be obtained from the SSARegMap for the function: given a MachineFunction, use something like: NumVRegs = MF.getSSARegMap()->getLastVirtReg()+1; These also start from MRegisterInfo::FirstVirtual...

One of my pass requires LiveIntervals to build the interference graph, because LiveVariables do not provide an interface to iterate through all viritual registers. But LiveIntervalAnalysis.h is not in "include/llvm/CodeGen", so I have to either include it by: #include "../../llvm/lib/CodeGen/LiveIntervalAnalysis.h" or point my project include path to

...t nondot.org> wrote: > > because LiveVariables do not provide an interface to iterate through > > all viritual registers. > > Ok, you could add a method to LiveVariables that returns > VirtRegInfo.size(). The virtual registers are defined by the range: > [MRegisterInfo::FirstVirtualRegister, > MRegisterInfo::FirstVirtualRegister+VirtRegInfo.size()] > > Alternatively, the same information can be obtained from the SSARegMap for > the function: given a MachineFunction, use something like: > > NumVRegs = MF.getSSARegMap()->getLastVirtReg()+1; > > These also...

On Jan 6, 2011, at 10:11 PM, andrew at sidefx.com wrote: > Would it be possible to increase TargetRegisterInfo::FirstVirtualRegister > to something quite a bit larger - such as 2^31? I'm working on a target > where all SSA values need to be assigned physical registers, and the > current limit of 16384 may limit the size of programs that I'm able to > handle. 2^31 is a nice value since there are equal number...

On Jan 6, 2011, at 10:39 PM, andrew at sidefx.com wrote: > >> If you're interested in doing this, I'd suggest hacking up the backend to >> not run register allocation, and represent all your "physical" registers >> are virtual registers. This gives you an unlimited number. >> > > Yes it would be ideal to use all virtual registers, but a

> If you're interested in doing this, I'd suggest hacking up the backend to > not run register allocation, and represent all your "physical" registers > are virtual registers. This gives you an unlimited number. > Yes it would be ideal to use all virtual registers, but a glance at the code seemed to indicate the the use of physical registers, spilling, etc. was

...e: >>> because LiveVariables do not provide an interface to iterate through >>> all viritual registers. >> >> Ok, you could add a method to LiveVariables that returns >> VirtRegInfo.size(). The virtual registers are defined by the range: >> [MRegisterInfo::FirstVirtualRegister, >> MRegisterInfo::FirstVirtualRegister+VirtRegInfo.size()] >> >> Alternatively, the same information can be obtained from the SSARegMap for >> the function: given a MachineFunction, use something like: >> >> NumVRegs = MF.getSSARegMap()->getLastVirtReg()+1;...

...; Index: include/llvm/Target/TargetRegisterInfo.h > =================================================================== > --- include/llvm/Target/TargetRegisterInfo.h    (revision 89468) > +++ include/llvm/Target/TargetRegisterInfo.h    (working copy) > @@ -299,8 +299,8 @@ >      /// FirstVirtualRegister - This is the first register number that is >      /// considered to be a 'virtual' register, which is part of the SSA >      /// namespace.  This must be the same for all targets, which means that each > -    /// target is limited to 1024 registers. > -    FirstVirtualRegister...

...Index: include/llvm/Target/TargetRegisterInfo.h > =================================================================== > --- include/llvm/Target/TargetRegisterInfo.h (revision 89468) > +++ include/llvm/Target/TargetRegisterInfo.h (working copy) > @@ -299,8 +299,8 @@ > /// FirstVirtualRegister - This is the first register number that is > /// considered to be a 'virtual' register, which is part of the SSA > /// namespace. This must be the same for all targets, which means that each > - /// target is limited to 1024 registers. > - FirstVirtualRegiste...

This caused a massive slow down to post-ra scheduler (llc -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. Evan On Dec 7, 2009, at 11:39 AM, Dan Gohman wrote: > > On Dec 7, 2009, at 11:15 AM, Pekka Jääskeläinen wrote: > >> Here's the actual patch, sorry ;) > > Applied in r90789. > > Dan > > >

...ler (llc -O3 on x86, -O2 on ARM). I'm going to revert it for now until it has been addressed. Probably caused by this member: /// KillIndices - The index of the most recent kill (proceding bottom-up), /// or ~0u if the register is not live. unsigned KillIndices[TargetRegisterInfo::FirstVirtualRegister]; And this: std::fill(KillIndices, array_endof(KillIndices), ~0u); It should probably be dynamically allocated with TRI->getNumRegs() members instead. /jakob

...ers was removed, but it seems that this limit has returned in 3.1 with the use of uint16_t for register ids. Would it be possible to re-increase this storage size to uint32_t or to change this to a typedef so that I can patch it locally? See related thread "Increasing TargetRegisterInfo::FirstVirtualRegister" Andrew

No, there isn't something like that right now. What are you trying to accomplish? If you wish to implement this, it shouldn't be hard to do. Right now, MachineRegisterInfo re-starts virtual register number at TargetRegisterInfo::FirstVirtualRegister. You can add a mechanism to change that to a variable instead. Evan On Oct 20, 2008, at 1:43 PM, Villmow, Micah wrote: > Is there currently a way to have virtual register allocation > information be saved across functions so that if I create a new > virtual register in a function...

Hello everybody, hi Evan, this patch changes the lowering of arguments for tail call optimized calls. Before arguments that could be overwritten by each other were explicitly lowered to a stack slot, not giving the register allocator a chance to optimize. Now a sequence of copyto/copyfrom virtual registers ensures that arguments are loaded in (virtual) registers before they are lowered to the