search for: reg16389

Displaying 7 results from an estimated 7 matches for "reg16389".

Did you mean: reg16384
2010 Sep 05
2
[LLVMdev] Possible missed optimization?
...%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>, pred:14, pred:%reg0 76L %reg16390<def>, %CPSR<def,dead> = tMOVi8 18, pred:14, pred:%reg0 88L %reg16391<def> = COPY %reg16390<kill> 96L...
2010 Sep 05
0
[LLVMdev] Possible missed optimization?
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
2010 Sep 04
3
[LLVMdev] Possible missed optimization?
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
2010 Oct 29
1
[LLVMdev] [LLVMDev] Register Allocation and Kill Flags
...6384 %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 have # After Register Allocation: # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at locat...
2010 Dec 15
2
[LLVMdev] Optimization passes break machine instructions on new backend
...ccording 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<def> = COPY %reg16389; IntRegs:%reg16389 RET # End machine code for function func. -print-before-all indicates that the machines code sinking pass is wrecking this, because...
2010 Nov 27
3
[LLVMdev] Register Pairing
...85 // 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 OF B %reg16391<def> = ADDRdRr %reg16388, %reg16387<kill>, %SREG<imp-def>; GPR8:%reg1...
2010 Nov 24
1
[LLVMdev] Selecting BRCOND instead of BRCC
...= 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] 0x170e060: i16 = Register %reg16389 [ID=3] 0x170e960: ch = CopyToReg 0x16d5748, 0x170e860, 0x170e360 [ID=17] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x170e860: i16 = Register %reg16386 [ID=7] 0x170e360: i16,ch = CopyFromReg 0x16d5748, 0x170e260 [ID=14] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x1...