similar to: [LLVMdev] Reduced physical register limit in 3.1+?

Hello, This patch was reverted and the revert was forgotten to be undone after the performance regression it introduced was fixed. Can someone please revert it back (i.e. increase the max physreg size to 16K or even better to 32K) to enable us to experiment with large register number machines again? :) It was this trivial patch: Index: include/llvm/Target/TargetRegisterInfo.h

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 physical and virtual registers,

On Dec 8, 2009, at 3:31 PM, Jakob Stoklund Olesen wrote: > > On Dec 8, 2009, at 11:33 AM, Evan Cheng wrote: > >> 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. > > Probably caused by this member: > > /// KillIndices - The index of the most recent kill (proceding

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?

Hello, I haven't yet received any input what this patch breaks (some LLVM-external project?) and the branch creation date is tomorrow. Can someone please tell what we can do to make this patch merged in for 2.8? Thanks! On 07/06/2010 01:26 PM, Pekka Jääskeläinen wrote: > Hello, > > This patch was reverted and the revert was forgotten to be undone > after the performance

On Dec 8, 2009, at 11:33 AM, Evan Cheng wrote: > 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. 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

hi Jääskeläinen, i am very interesting in the way you write the RegisterInfo.td for the machine with such a lot registers, or it is generated by some others program? best regards ether 2010/7/6 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>: > Hello, > > This patch was reverted and the revert was forgotten to be undone > after the performance regression it introduced was

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

> 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

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

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

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

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 > > >

I'm targeting a language that uses virtual registers and not physical registers. So the easiest way to implement this is to use virtual registers, except that they are being restarted after each function and clobbering registers in previous functions. For example: start function 0 r1024 = mov %var0.0 r1025 = mov %var0.1 lots of intermediate code call function1 w/ 3 parameters more

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 that it doesn't use a virtual register allocated in any previous function? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. 4555 Great America Pkwy, Santa Clara, CA. 95054

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

I have a Module/LLVMContext that I'd like to clone and manipulate in different threads (each thread may perform different translation / optimization, so they need unique copies). Currently this process has to be locked, since each clone of the Module still refers to the same LLVMContext. Is there a way to clone both the Module and LLVMContext so that the copies can be manipulated

On Tue, 20 Sep 2005, Tzu-Chien Chiu wrote: > One of my pass requires LiveIntervals 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,

On 20/09/05, Chris Lattner <sabre at 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, >

Thanks for the reply! Unfortunately, that seems to have the same effect as setting llvm::TimePassesIsEnabled myself, and all my same problems still apply as the TimingInfo's destructor (PassManager.cpp) is still never called. Running it in the debugger shows that TimerGroup's removeTimer method is never called, nor is it's destructor (but it's constructor is). On Wed, Jun 1, 2011