search for: r25r24

...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>; DREGS:%vreg0 Considering merging %vreg0 with physreg %R25R24 RHS = %vreg0 = [16d,96d:0) 0 at 16d LHS = %R25R24,inf = [0L,16d:0) 0 at 0L-phidef updated: 96L %vreg8<def> = COPY %R25R24<kill>; PTRREGS:%vreg8 updated: 32L %vreg5<de...

...gt; 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>; DREGS:%vreg0 > Considering merging %vreg0 with physreg %R25R24 > RHS = %vreg0 = [16d,96d:0) 0 at 16d > LHS = %R25R24,inf = [0L,16d:0) 0 at 0L-phidef > updated: 96L %vreg8<def> = COPY %R25R24<kill>; PTRREGS:%vreg8 > upd...

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:

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

...Incoming args come in register pairs, split them into the 8bit subregs perform the addition and combine them again into the pair ready for the next operation, in this case we're returning the result. This gives me this code before instr sel: # Machine code for function foo: Function Live Ins: %R25R24 in reg%16384, %R23R22 in reg%16385 Function Live Outs: %R25R24 BB#0: derived from LLVM BB %entry Live Ins: %R25R24 %R23R22 %reg16385<def> = COPY %R23R22; WDREGS:%reg16385 // COPY B %reg16384<def> = COPY %R25R24; WDREGS:%reg16384 // COPY A %reg16387<def> = COPY %...

..., 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 %vreg0<def> = COPY %R25R24; DREGS:%vreg0 %vreg2<def> = COPY %vreg0; PTRREGS:%vreg2 DREGS:%vreg0 %vreg1<def> = LDWRd %vreg2; mem:LD2[%a](align=1)(tbaa=!"int") DLDREGS:%vreg1 PTRREGS:%vreg2 %vreg3<def> = ANDIWRdK %vreg1, 255; DLDREGS:%vreg3,%vreg1...

Hello, I noticed the following interesting code sequence while compiling a piece of code with the backend I'm developing. Probably this issue is for Jakob, but anyways this is what I'm getting: STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) STDWPtrQRr <fi#13>, 0, %R23R22; mem:ST2[FixedStack13](align=1) STDWPtrQRr <fi#13>, 0, %R23R22; mem:ST2[FixedStack13](align=1) STDWPtrQRr <fi#14>, 0, %R21R20; mem:ST...

...2, at 10:20 AM, Borja Ferrer wrote: > Hello, > > I noticed the following interesting code sequence while compiling a piece of code with the backend I'm developing. Probably this issue is for Jakob, but anyways this is what I'm getting: > > STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) > STDWPtrQRr <fi#12>, 0, %R25R24; mem:ST2[FixedStack12](align=1) > STDWPtrQRr <fi#13>, 0, %R23R22; mem:ST2[FixedStack13](align=1) > STDWPtrQRr <fi#13>, 0, %R23R22; mem:ST2[FixedStack13](align=1) > STDWPtrQRr <fi#14>...

...de order is all botched up. For example, given this input: SelectionDAG has 8 nodes: t0: ch = EntryToken t2: i16,ch = CopyFromReg t0, Register:i16 %vreg0 t5: i16,ch = load<Volatile LD2[%1](align=1)(dereferenceable)> t0, t2, undef:i16 t7: ch,glue = CopyToReg t5:1, Register:i16 %R25R24, t5 t8: ch = RET_FLAG t7, Register:i16 %R25R24, t7:1 The resulting output is SelectionDAG has 8 nodes: t0: ch = EntryToken t7: ch,glue = CopyToReg t10:1, Register:i16 %R25R24, t10 t2: i16,ch = CopyFromReg t0, Register:i16 %vreg0 t9: i16,i16,ch = LDWRdPtr<Mem:Volatile LD2[%1](a...

...you don't have a number of 16-bit instructions. [...] > typedef unsigned short t; > t foo(t a, t b, t c) > { > return a+b; > } [...] > This is fine until we get to the register allocation stage, there it does: > BB#0: derived from LLVM BB %entry > Live Ins: %R25R24 %R23R22 > %R18<def> = COPY %R24 > %R19<def> = COPY %R25 > %R24<def> = COPY %R22<kill>, %R25R24<imp-def> > %R24<def> = ADDRdRr %R24, %R18<kill>, %SREG<imp-def> > %R25<def> = COPY %R23<kill> > %R25&l...

...he 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 R27R26 since it belongs to the ptr reg class and not R25R24 where the "a" ptr is. As a test i made the load/store instructions work with the DREGS which is the main class and the problem was solved, but of course this is illegal code :) The coalescer cannot join copies with disjoint register classes. You need to make sure that there is a registe...