similar to: [LLVMdev] Increasing TargetRegisterInfo::FirstVirtualRegister?

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

> 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

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

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

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

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

I noticed that in LLVM 3.0 the limit of 16K physical registers 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

I have tested the register allocation in llvm, using: $llc -debug test.bc where, test.c is like: int a, b, c, d, x; a = 3; b = 5; d = 4; x = 100; if ( a > b ) ...... And I got the machine code before register allocation: MOV32mi <fi#2>, 1, %reg0, 0, %reg0, 3; mem:ST4[%a] MOV32mi <fi#3>, 1, %reg0, 0, %reg0,

Hi, while writing my register allocator, I have come across a case which confuses me because the llvm definition cannot be mapped to machine code. For instance I come across (1) and I reduce it to (2). However a copy instruction cannot move from EDX to CX. What mechanics in LLVM will tell me that I cannot make this move during register allocation, or how can I tell from (1) that I cannot execute

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

I am wondering about register allocation when there is a kill flag on the MachineOperand. Do I need to remove the kill flag? This code below is just an example from test\CodeGen\X86\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB

On Nov 8, 2010, at 12:04 PM, Jeff Kunkel wrote: > Hi, while writing my register allocator, I have come across a case which confuses me because the llvm definition cannot be mapped to machine code. > > For instance I come across (1) and I reduce it to (2). However a copy instruction cannot move from EDX to CX. What mechanics in LLVM will tell me that I cannot make this move during

On Sep 4, 2010, at 5:40 PM, Eli Friedman wrote: > If you want to take a look at this yourself, the issue is easy to > reproduce with Thumb1: Thanks, Eli. Nice catch! This IR: target triple = "thumbv5-u-u" define arm_aapcscc i64 @foo(i64 %a, i64 %b) nounwind readnone { entry: %xor = xor i64 %a, 18 ; <i64> [#uses=1] %xor2 = xor i64 %xor, %b

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

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

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