search for: reg16388

...2 = xor i64 %xor, %b ; <i64> [#uses=1] ret i64 %xor2 } produces these instructions before coalescing: 4L %reg16387<def> = COPY %R3<kill> 12L %reg16386<def> = COPY %R2<kill> 28L %reg16384<def> = COPY %R0<kill> 36L %reg16388<def> = COPY %reg16385<kill> 44L %reg16388<def>, %CPSR<def,dead> = tEOR %reg16388, %reg16387<kill>, pred:14, pred:%reg0 56L %reg16389<def> = COPY %reg16384<kill> 64L %reg16389<def>, %CPSR<def,dead> = tEOR %reg16389, %reg16386<kill&...

On Sat, Sep 4, 2010 at 1:31 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Sep 4, 2010, at 11:21 AM, Borja Ferrer wrote: > >> I've noticed this pattern happening with other operators aswell, but used xor in this example. As i said before, i tried with different register allocation orders, but it will produce always the same result. GCC is emitting longer

On Sep 4, 2010, at 11:21 AM, Borja Ferrer wrote: > I've noticed this pattern happening with other operators aswell, but used xor in this example. As i said before, i tried with different register allocation orders, but it will produce always the same result. GCC is emitting longer code, but since LLVM is so nearer to the optimal code sequence i wanted to reach it. In LLVM, copies are

...(integer) subregisters. Subregisters of same reg *never* overlap. Therefore, vector loads are lowered to scalar loads followed by a chain of INSERT_VECTOR_ELTs. Then we select those to INSERT_SUBREG, everything fine to that point. Status before live analisys is (non-related instrs removed): 36 %reg16388<def> = LDWr %reg16384, 0; mem:LD4[<unknown>] 68 %reg16392<def> = INSERT_SUBREG %reg16392<undef>, %reg16388<kill>, 1 76 %reg16394<def> = LDWr %reg16386<kill>, 0; mem:LD4[<unknown>] 116 %reg16400<def> = MOVEV %reg16392<kill> 124 %reg16400&lt...

...tion [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB %entry %reg16385<def> = MOV32rm <fi#-2>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-2] GR32:%reg16385 %reg16384<def> = MOV32rm <fi#-1>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-1] GR32:%reg16384 %reg16388<def> = MOV32ri 1; GR32:%reg16388 %reg16392<def> = XOR32ri %reg16385, 4294967294, %EFLAGS<imp-def>; GR32:%reg16392,16385 %reg16391<def> = AND32rr *%reg16392<kill>*, %reg16384, %EFLAGS<imp-def>; GR32:%reg16391,16392,16384 %reg16389<def> =...

...7<def> = COPY %R3; IntRegs:%reg16387 %reg16386<def> = COPY %R2; IntRegs:%reg16386 %reg16385<def> = COPY %R1; IntRegs:%reg16385 %reg16384<def> = COPY %R0; IntRegs:%reg16384 %reg16390<def> = MOVE %reg16386; IntRegs:%reg16390,16386 %reg16388<def> = CMPrr %reg16384, %reg16385, %CFR<imp-def,dead>; IntRegs:%reg16388,16384,16385 SKIPCOND 1, %CFR<imp-use> Successors according to CFG: BB#2 BB#1 BB#1: derived from LLVM BB %entry Predecessors according to CFG: BB#0 %reg16391<def> = MOVE %reg1638...

...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 %reg16384:ssub_0; GPR8:%reg16387 WDREGS:%reg16384 // EXTRACT LO BYTE OF A %reg16388<def> = COPY %reg16385:ssub_0; GPR8:%reg16388 WDREGS:%reg16385 // EXTRACT LO BYTE OF B %reg16389<def> = COPY %reg16384:ssub_1; GPR8:%reg16389 WDREGS:%reg16384 // EXTRACT HI BYTE OF A %reg16390<def> = COPY %reg16385:ssub_1; GPR8:%reg16390 WDREGS:%reg16385 // EXTRACT HI BYTE...

...= CopyToReg 0x16d5748, 0x170e460, 0x170df60 [ID=15] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x170e460: i16 = Register %reg16384 [ID=5] 0x170df60: i16,ch = CopyFromReg 0x16d5748, 0x170de60 [ID=12] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x170de60: i16 = Register %reg16388 [ID=2] 0x170e760: ch = CopyToReg 0x16d5748, 0x170e660, 0x170e160 [ID=16] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x170e660: i16 = Register %reg16385 [ID=6] 0x170e160: i16,ch = CopyFromReg 0x16d5748, 0x170e060 [ID=13] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x1...

Hello Per, > The CMPrr instruction is moved down to after the PHI node. My guess is that > the 'dead' in CFR<imp-def,dead> is to blame, but I can't see what I'm doing > differently from MSP430/sparc that makes this not work. Any help GREATLY > appreciated! It seems like no use of CFR after CMP, indeed. How condbranches on your platform look like (patterns, etc.)

But in the first version it's used on the next row: %reg16388<def> = CMPrr %reg16384, %reg16385, %CFR<imp-def,dead>; IntRegs:%reg16388,16384,16385 SKIPCOND 1, *%CFR<imp-use>* Or doesn't that count? Following are patters for cmp and skipcond: def cmpcc : SDNode<"CSISD::CMP", SDTIntBinOp, [SDNPOutFlag]>; let Defs = [...

...> 68 %reg16392<def> = LDWr %reg16384<kill>, 0; mem:LD4[<unknown>] > 76 %reg16393<def> = LDWr %reg16386<kill>, 0; mem:LD4[<unknown>] > 84 %reg16394<def> = LDWr %reg16387<kill>, 0; mem:LD4[<unknown>] > 92 %reg16395<def> = LDWr %reg16388<kill>, 0; mem:LD4[<unknown>] > 132 %reg16400:1<def,dead> = MOVI32rr %reg16392<kill> > 140 %reg16400:2<def> = MOVI32rr %reg16393<kill> > 148 %reg16400:3<def> = MOVI32rr %reg16394<kill> > 156 %reg16400:4<def> = MOVI32rr %reg16395<ki...