search for: allocatability

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

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. Say I have regclass1 with reg A, and regclass2 with regs {A, B}, but regclass2 defines only

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,

> 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, Arnaud From:

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) The sum of the maximum number of registers aliased by any

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

Hi, I have run into a test case on an out-of-tree target where PBQP fails to complete register allocation after "Attempting to spill already spilled value" (the triggered assert in InlineSpiller::spill(). First, the original LiveInterval is spilled. It is a load of a symbol into a narrow register class, i.e. a subset of the class of address registers. InlineSpiller decides to

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 +

...nstructions. Why does LiveVariables assume physical registers are only live within a single basic block? I have confirmed that if I remove the allocatable check in runOnBlock() [if (!TRI->isInAllocatableClass(LI.PhysReg))] and instead add all successor live-ins to LiveOuts regardless of regclass allocatability, my copy is not marked dead and not subsequently eliminated. This seems consistent with the aforementioned comment, so I don't think it's a bug but I really don't understand the intention here. If anyone could shed some light on why allocatable live-in's are pretty much ignored here...

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(

- Re-sending to include llvm-dev. HI Jonas, This is great - thank you very much for your analysis! You're spot on about Bug 1 - the row/column checks are transposed there. I have fixed this in r227628. Regarding Bug 2, as discussed on the other thread I'm going to teach the register allocator to prune single-option vregs so that they never make it into the graph. I haven't had a

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

While working on a back-end for a target, I've come across something I believe 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

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