search for: reg16391

...t location [SP+4] Function Live Outs: %AX BB#0: derived from LLVM BB %entry %reg16390<def> = MOVZX32rm16 <fi#-2>, 1, %reg0, 0, %reg0; mem:LD2[FixedStack-2] GR32:%reg16390 %reg16385<def> = COPY %reg16390:sub_16bit<kill>; GR16:%reg16385 GR32:%reg16390 %reg16391<def> = MOVZX32rm16 <fi#-1>, 1, %reg0, 0, %reg0; mem:LD2[FixedStack-1] GR32:%reg16391 %reg16384<def> = COPY %reg16391:sub_16bit<kill>; GR16:%reg16384 GR32:%reg16391 Successors according to CFG: BB#1 ... 2: BB#0: derived from LLVM BB %entry %EDX<def>...

...7<kill>, pred:14, pred:%reg0 56L %reg16389<def> = COPY %reg16384<kill> 64L %reg16389<def>, %CPSR<def,dead> = tEOR %reg16389, %reg16386<kill>, pred:14, pred:%reg0 76L %reg16390<def>, %CPSR<def,dead> = tMOVi8 18, pred:14, pred:%reg0 88L %reg16391<def> = COPY %reg16390<kill> 96L %reg16391<def>, %CPSR<def,dead> = tEOR %reg16391, %reg16389<kill>, pred:14, pred:%reg0 108L %R0<def> = COPY %reg16391<kill> 116L %R1<def> = COPY %reg16388<kill> 128L tBX_RET %R0<imp-use,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

...d I handle this case. > BB#0: derived from LLVM BB %entry > %reg16390<def> = MOVZX32rm16 <fi#-2>, 1, %reg0, 0, %reg0; mem:LD2[FixedStack-2] GR32:%reg16390 > %reg16385<def> = COPY %reg16390:sub_16bit<kill>; GR16:%reg16385 GR32:%reg16390 > %reg16391<def> = MOVZX32rm16 <fi#-1>, 1, %reg0, 0, %reg0; mem:LD2[FixedStack-1] GR32:%reg16391 > %reg16384<def> = COPY %reg16391:sub_16bit<kill>; GR16:%reg16384 GR32:%reg16391 > Successors according to CFG: BB#1 MachineOperands can refer to sub-registers of virtual...

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

...k-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> = SHR32ri %reg16391, 1, %EFLAGS<imp-def>; GR32:%reg16389,16391 %EAX<def> = COPY %reg16389; GR32:%reg16389 RET After my reg allocation I...

...s:%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 %reg16387; IntRegs:%reg16391,16387 Successors according to CFG: BB#2 BB#2: derived from LLVM BB %entry Predecessors according to CFG: BB#0 BB#1 %reg16389<def> = PHI %reg16390, <BB#0>, %reg16391, <BB#1>; IntRegs:%reg16389,16390,16391 %R0&l...

...; = 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 OF B %reg16391<def> = ADDRdRr %reg16388, %reg16387<kill>, %SREG<imp-def>; GPR8:%reg16391,16388,16387 // ADD LO BYTES %reg16392<def> = ADCRdRr %reg16390, %reg16389<kill>, %SREG<imp-def,dead>, %SREG<imp-use>; GPR8:%reg16392,16390,16389 // ADDC HI BYTES %reg16393<...