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...