search for: allocatables

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 if a register is in the set of registers accessible by a given unit.

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

On Sep 13, 2010, at 6:59 AM, Carlos Sánchez de La Lama wrote: > Hi people, > > the LinearScan register allocator tries to use same register for both > live intervals, if the new interval 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. >

...p; allocatableRegs_[Reg] && RC->contains(Reg)) mri_->setRegAllocationHint(cur->reg, 0, Reg); where "allocatableRegs_" is calculated during pass init, and ignores register class. I think this should be changed to: if (Reg && (tri_->getAllocatableSet(*mf_, RC))[Reg] && RC- >contains(Reg)) mri_->setRegAllocationHint(cur->reg, 0, Reg); or, if compilation speed discourages calling "getAllocatableSet" so often, create "allocatableRegs_" array per register-class, instead of just one. If it...

On 29 March 2014 13:38, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > I disagree. It is the *easy* part to get many known users to work. This > includes 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,

...n, 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 of it’s neigbhour invoked handleDisconnectEdge(), and moves it into conservatively-allocatables, because DeniedOpts had become less than NumOpts (in isConservativelyAllocatable(). * There are lots of spillable nodes being popped before the one that can’t be spilled. This seems intui...

...velyAllocatableNodes 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 of it’s neigbhour invoked handleDisconnectEdge(), and moves it > into conservatively-allocatables, because DeniedOpts had become less than > NumOpts (in isConservativelyAllocatable(). > > * There are lots of spillable nodes being popped before the one that can’t >...

...rbose-PBQP-dump patch and use '-debug-only=regalloc -pbqp-dump-graphs' to see the more verbose output which shows the progress of the algorithm leading to the assert: * Applied R2(NId 18)handleDisconnectEdge(9, 2) : DeniedOpts 10 -> 9 NId 9(%vreg15, GPR64common) moved to conservatively-allocatables. handleDisconnectEdge(2, 9) : DeniedOpts 10 -> 9 NId 2(%vreg4, GPR64common) moved to conservatively-allocatables. ... Popped NId 2(%vreg4, GPR64common) , all edge costs added: 2.002748e+01 inf inf inf inf inf inf inf inf inf inf ** selection: 0 llc: ../include/llvm/CodeGen/PBQP/ReductionRules.h...

...he 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 of it's neigbhour invoked handleDisconnectEdge(), and moves it into conservatively-allocatables, because DeniedOpts had become less than NumOpts (in isConservativelyAllocatable(). * There are lots of spillable nodes being popped before the one that can't be spilled. This seem...

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 +

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" > </div> <div dir="ltr" >Hi all,</div> <div dir="ltr" > </div> <div

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(

...;-debug-only=regalloc -pbqp-dump-graphs' to see the more verbose output > which shows the progress of the algorithm leading to the assert: > > > > * Applied R2(NId 18)handleDisconnectEdge(9, 2) : DeniedOpts 10 -> 9 > > NId 9(%vreg15, GPR64common) moved to conservatively-allocatables. > > handleDisconnectEdge(2, 9) : DeniedOpts 10 -> 9 > > NId 2(%vreg4, GPR64common) moved to conservatively-allocatables. > > ... > > Popped NId 2(%vreg4, GPR64common) , all edge costs added: > > 2.002748e+01 inf inf inf inf inf inf inf inf inf inf ** selection: 0...

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

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

...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, tri_->getAllocatableSet(fn, *I))); If the allocatable registers are dependent on the function, such as might occur when a frame pointer isn't required, then it seems that every function will use the same allocatable set as the first function. [ a DenseMap insert operation has no effect if the key is already present...

> The best fix is to teach this scheduler how to deal with these > dependencies. :-) > > If you just want a check, I think it's easier to just check register > class's copy cost. -1 means it's extremely expensive to copy registers > in the particular register class. Evan, I am not sure what you mean by "if you just want a check" - I was trying to point out

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

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

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();