similar to: [LLVMdev] LLVM ERROR: ran out of registers during register allocation

On Dec 17, 2012, at 8:38 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: > > struct ss > { > int a; > int b; > int c; > }; > void

Hello Jakob, > Those are some severe constraints on register allocation, but it ought to > be possible anyway. > Indeed, these constraints aren't playing very well with the register allocator :\ > > You may wan't to investigate how RAGreedy::canEvictInterference() is > behaving. > Ok, this is what I've noticed, not sure if it makes sense at all but, regalloc

Hello Jakob, I think I've found something interesting that may help you get a better idea of what's going on. While looking at the debug info I noticed that the coalescer was removing lots of copies that could help the allocator make more cross class copies. As a test, I disabled the join-liveintervals option in the coalescer which gave me the surprise of making the regalloc succeed. To

Hello, I've noticed the following issue while testing some codegen tests, i would like to know if it's a missed optimization or i missed something out here. This is for an out of tree backend im writing. I managed to reduce it to the following C function: void foo(int *a) // int here is 16bits { *a &= 0xFF; } This is the code before regalloc: Live Ins: %R25R24

Hello, I'm getting a machine verifier error after introducing the earlyclobber constraint to some instructions where the src and dest regs can't be the same. The offending instruction pattern is this one: let canFoldAsLoad = 1, isReMaterializable = 1, Constraints = "@earlyclobber $dst" in def LDDWRdPtrQ : Inst<(outs DREGS:$dst), (ins memri:$src),

On Apr 26, 2011, at 1:27 PM, Borja Ferrer wrote: > Hello Jim thanks for the reply, > > For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: > def : Pat<(add DLDREGS:$src1, imm:$src2), > (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>;

On Jul 14, 2012, at 10:09 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting a machine verifier error after introducing the earlyclobber constraint to some instructions where the src and dest regs can't be the same. The offending instruction pattern is this one: > > let canFoldAsLoad = 1, > isReMaterializable = 1, > Constraints =

Thanks Jim, I've implemented the negation part successfully :) maybe the second part could be a possible feature request so others could use it aswell? 2011/4/27 Jim Grosbach <grosbach at apple.com> > > On Apr 26, 2011, at 1:27 PM, Borja Ferrer wrote: > > > Hello Jim thanks for the reply, > > > > For normal additions with immediates I've done the same as

Hello Jakob, I'm still getting the error, I can give you any other debug info you need. I haven't pasted the regalloc debug info here because it is quite huge, but if you tell me what specific details you need I will include them. Thanks for your help! 2012/7/14 Jakob Stoklund Olesen <stoklund at 2pi.dk> > > On Jul 14, 2012, at 10:09 AM, Borja Ferrer <borja.ferav at

Hello Jim thanks for the reply, For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: def : Pat<(add DLDREGS:$src1, imm:$src2), (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; Now, the typical pattern concerning additions with global addresses looks

Hello Jakob, thanks for the reply. The three regclasses involved here are all subsets from each other and aren't disjoint. These are the basic descriptions of the regclasses involved to show what i mean: DREGS: R31R30, R29R28 down to R1R0 (16 regs) DLDREGS: R31R30, R29R28 down to R17R16 (8 regs) PTRREGS: R31R30, R29R28, R27R26 (3 regs) All classes intersect each other

On Mar 24, 2011, at 5:42 PM, Borja Ferrer wrote: > The last copy instruction should be removed as pointed out above, but since R27R26 is killed in the load instruction it has to be emitted. About the insane amount of regclasses there, the load/store and the andi instructions take subsets of regs from the main register class, they cant work with all registers, that's why STW and LDW needs

Hi, I'd like to define a pseudo-instruction whose expansion will, as a side-effect, overwrite an input register's value: the pseudo-instruction ldw r1:r2, P to load 2 bytes from memory address P is to be expaneded to ld r1, P+ ld r2, P where "ld _, P+" is an instruction that loads a single byte from P, and post-increments P by one. How can I represent this behaviour in

On Mar 26, 2011, at 1:04 PM, Borja Ferrer wrote: > Hello Jakob, thanks for the reply. The three regclasses involved here are all subsets from each other and aren't disjoint. These are the basic descriptions of the regclasses involved to show what i mean: > > DREGS: R31R30, R29R28 down to R1R0 (16 regs) > DLDREGS: R31R30, R29R28 down to R17R16 (8 regs) > PTRREGS:

Are you primarily trying to avoid Expand being implemented as a lib call with a larger type? No - I’m stuck in this situation: - 8-bit addition is legal - 16-bit addition is illegal, should expand into an add and an add with carry - A few operations support 16-bit operands - the 16-bit DREGS register class The legalizer sees that 16-bit addition should expand. It sees that there

On Sun, 28 May 2017, David Chisnall wrote: >> let Constraints = "@earlyclobber $reg" in >> def LDWRdPtr : Pseudo<(outs DREGS:$reg), >> (ins PTRREGS:$ptrreg), >> "ldw\t$reg, $ptrreg", >> [(set i16:$reg, (load i16:$ptrreg))]>, >>

Jakob, one more hint, I've placed some asserts around the code you added and noticed that the InlineSpiller::insertReload() function is not being called. 2012/7/14 Borja Ferrer <borja.ferav at gmail.com> > Hello Jakob, > > I'm still getting the error, I can give you any other debug info you need. > I haven't pasted the regalloc debug info here because it is quite

> > You can look at the output of -debug-only=regcoalescing to see what is > going on. > > This is the debug output i've got, some information is a bit cryptic for me so next is what i understood: ********** SIMPLE REGISTER COALESCING ********** ********** Function: foo ********** JOINING INTERVALS *********** entry: 16L %vreg0<def> = COPY %R25R24<kill>;

On 11/20/2017 08:42 PM, Jens Axboe wrote: > On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:20 PM, Bart Van Assche wrote: >>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >>>> This is >>>> >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to

On 11/20/2017 08:42 PM, Jens Axboe wrote: > On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:20 PM, Bart Van Assche wrote: >>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >>>> This is >>>> >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to