search for: allocatable

I am using some non-allocatable RegisterClasses to define lists of registers that are used for various non-allocation-related processing in the back end. For example, we have a post-allocation functional unit selection pass that is guided by the register assignment, which does things like 'myRegClass.contains(Reg)' to see...

Hi Jakob, >> Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but >> regclass2 defines only "B" as allocatable by RA. > > The register allocator assumes in many places that a register is > either allocatable or reserved independently of the register class. Is there any reason for this? I mean, the methods for allowing one physical reg be considered allocatable to one regclass and not allocat...

...egister copy > whose destination reg is compatible with the source register. This is > ok. However, this "check for compatibility" is wrongly done IMHO. > > Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but > regclass2 defines only "B" as allocatable by RA. The register allocator assumes in many places that a register is either allocatable or reserved independently of the register class. That is, if a register is allocatable in one register class, it is assumed to be allocatable from all register classes where it is present. What are you try...

...nterval is defined by a register copy whose destination reg is compatible with the source register. This is ok. However, this "check for compatibility" is wrongly done IMHO. Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but regclass2 defines only "B" as allocatable by RA. A copy instruction: <regclass2 dst> = <regclass1 src> where src was allocated to register A will make dst be allocated also to A, even when it was defined as not allocatable in .td files. This is due to the checking in RegAllocLinearScan:1004 if (Reg && al...

...a bunch of kernels, Lisp implementations etc. The rest can be > implemented on top by hand using inline asm, so this is the crucial > part. Let me re-phrase my opinion... >From all discussions on the LLVM list, the one that has shown more consistently as a problem was the reservation of allocatable registers. Some background... My original intent was to be able to support the kernel unwinding code. There was a discussion, in which we agree that for that a building stack_pointer would do. But the GCC community has voiced two concerns: there is already a feature for that widely in use, and th...

> A node should never be put into the conservatively allocatable list if there is a chance of it spilling. I can understand why the logic of NodeMetadata::isConservativelyAllocatable is necessary for the node to be allocatable, but I have not been able to convince myself this is sufficient, especially when the node degree > available registers. Cheers...

Hi Arnaud, The conservatively allocatable test is supposed to check two conditions, either of which would be sufficient to make a node allocatable: (1) There exists some register that is not aliased by any register option for any neighbor. This is the "safe row" test. It is straightforward, but likely to fire only rarely. (2) T...

Hi, Sorry for the delay, it has taken some extra time as more than one bug showed up ☺ I continued to look into this with your viewpoint that a node that is conservatively allocatable should never be spilled. The first thing I did was therefore to add some extra code with an assert for this. I believe I then found three bugs and fixed the two: Bug 1: Incorrect transpositions in handleAddEdge() / hanldeRemoveEdge(). For the heuristic of DeniedOpts, if N runs along the columns (...

...w reg-class, and the cost vector has become all infinities. Spill option is selected again, and thus the error is a fact of spilling an already spilled value. I wonder what has gone wrong here, and have some initial thoughts: * The problematic node that was spilled again, was in the ConservativelyAllocatableNodes set during reduce(). The comment in reduce() "Conservatively allocatable nodes will never spill..." indicates that perhaps this is an incorrect insertion, as the regs did in fact run out in this case. In setup(), the node is first put into not-provably-allocatables. However, one o...

I've noticed that LLVM does a bad job of optimizing array indexing code for FORTRAN arrays declared using the ALLOCATABLE keyword. For example if you have something like the following: DOUBLE PRECISION,ALLOCATABLE,DIMENSION(:,:,:,:) :: QAV ... ALLOCATE( QAV( -2:IMAX+2,-2:JMAX+2,-2:KMAX+2,ND) ) ... DO L = 1, 5 DO K = K1, K2 DO J = J1, J2 DO I = I1, I2 II = I + IADD IBD = II...

...p of LiveVariables.cpp states the following:<br><br> "It ... assumes that physical registers are only live within a single basic block (allowing it to do a single local analysis to resolve physical register lifetimes in each basic block). If a physical register is not register allocatable, it is not tracked. "</div> <div dir="ltr" > </div> <div dir="ltr" >This is consistent with the behaviour I'm witnessing, but I don't understand why it's designed this way. I am developing an out-of-tree backend and I have the following s...

Hi Wonsun, can you please provide a testcase. Best wishes, Duncan. > I've noticed that LLVM does a bad job of optimizing array indexing > code for FORTRAN arrays declared using the ALLOCATABLE keyword. > > For example if you have something like the following: > > DOUBLE PRECISION,ALLOCATABLE,DIMENSION(:,:,:,:) :: QAV > ... > ALLOCATE( QAV( -2:IMAX+2,-2:JMAX+2,-2:KMAX+2,ND) ) > ... > DO L = 1, 5 > DO K = K1, K2 > DO J = J1, J2 > DO I =...

...9:19 AM, Jonas Paulsson <jonas.paulsson at ericsson.com > wrote: > Hi, > > > > Sorry for the delay, it has taken some extra time as more than one bug > showed up J > > > > I continued to look into this with your viewpoint that a node that is > conservatively allocatable should never be spilled. The first thing I did > was therefore to add some extra code with an assert for this. > > > > I believe I then found three bugs and fixed the two: > > > > Bug 1: Incorrect transpositions in handleAddEdge() / hanldeRemoveEdge(). > For the heuris...

Hi, I'm writing to ask the differences between a "reserved" register and an "unallocable" register. In X86 backend, for example, the stack pointer register and instruction pointer are reserved but allocatable. In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, it says that a reserved register is one that *has particular uses and should be considered unavailable at all times. *If it is unavailable at all times, why not make such a reserved register unallocatable? Thanks! Rega...

On Apr 17, 2012, at 9:09 PM, Lei Mou wrote: > I'm writing to ask the differences between a "reserved" register and an "unallocable" register. In X86 backend, for example, the stack pointer register and instruction pointer are reserved but allocatable. In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs, it says that a reserved register is one that has particular uses and should be considered unavailable at all times. If it is unavailable at all times, why not make such a reserved register unallocatable? Thanks! Regist...

...to be a bug in SimpleRegisterCoalescing.cpp. I'm unsure how / whether to report it because I don't think it will necessarily crash or generate incorrect code for any of the supported targets. I believe that there may be a problem in SimpleRegisterCoalescing::runOnMachineFunction where the allocatable registers for each register class are initialised for the function, i.e. the lines: for (TargetRegisterInfo::regclass_iterator I = tri_->regclass_begin(), E = tri_->regclass_end(); I != E; ++I) allocatableRCRegs_.insert(std::make_pair(*I,...

...a 'flag' dependency than one to be resolved by the scheduler. So the question would be if these assumptions are correct and if it is safe to exclude implicitly defined physreg dependencies from the assert the way I proposed. Furthermore, I was thinking that the exception should not apply on allocatable registers, since the scheduler propably really cannot handle such. When I realized that X86 EFLAGS is actually allocatable, I was wondering why, but there is certainly a reason... Best regards, Christian -- please ignore: CONFIDENTIAL NOTICE: The contents of this message, including any at...

I am observing poor instruction scheduling in my out-of-tree target. The problem is an over-constrained scheduling DAG. In particular, the DAG includes spurious output dependencies on physical, non-register-allocatable registers. MISched already includes code to avoid this problem. However that code relies on information clobbered by the earlier pass LiveVariables. I wonder whether this is a bug in the LiveVariables pass and would appreciate feedback. Let me expand with a small example, Suppose my target dec...

Chris Lattner-2 wrote: > > > On Feb 11, 2009, at 4:07 AM, Alex wrote: > >> In my hardware there are two special registers cannot be copied but >> can only be assigned and referenced (read) in the other instruction. >> They are allocatable also. >> >> br i1 %if_cond, label %then, label %else >> then: >> %x1 = fptosi float %y1 to i32 >> br label %endif >> else: >> %x2 = fptosi float %y2 to i32 >> br label %endif >> endif: >> %x3 = phi i32 [%x1, %then], [%x2, %else]...

On Apr 29, 2010, at 2:06 PM, Villmow, Micah wrote: > Ping. Anyone have any idea on how to fix this? Does your getAllocatableSet() return a BitVector that is at least getNumRegs() bits long? Otherwise this doesn't work: BitVector NonAllocatableRegs = TRI->getAllocatableSet(MF); NonAllocatableRegs.flip();