Displaying 18 results from an estimated 18 matches for "reg16386".
Did you mean:
reg16384
2010 Dec 15
2
[LLVMdev] Optimization passes break machine instructions on new backend
...nitially correct:
# Machine code for function func:
Function Live Ins: %R0 in reg%16384, %R1 in reg%16385, %R2 in reg%16386, %R3
in reg%16387
Function Live Outs: %R0
BB#0: derived from LLVM BB %entry
Live Ins: %R0 %R1 %R2 %R3
%reg16387<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<im...
2010 Jul 28
3
[LLVMdev] Subregister coalescing
...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<def> = INSERT_SUBREG %reg16400, %reg16394<kill>, 2
132 %reg16401<def> = LDWr %reg16390<kill>, 0; mem:LD4[<unknown>]
164 %reg16404<def> = MOVEV %reg16400&...
2010 Sep 05
2
[LLVMdev] Possible missed optimization?
...nwind readnone {
entry:
%xor = xor i64 %a, 18 ; <i64> [#uses=1]
%xor2 = 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 %reg16...
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
2011 Jun 14
0
[LLVMdev] Too many load/store in Machine code represtation
...r accessing variable in stack
slot. The following message is use "llc -march=ppc32" command and dump from
MachineFunction.
%reg16384<def> = LWZ 0, <fi#6>; mem:LD4[%b] GPRC:%reg16384
%reg16385<def> = LWZ 0, <fi#5>; mem:LD4[%c] GPRC:%reg16385
%reg16386<def> = ADD4 %reg16384<kill>, %reg16385<kill>;
GPRC:%reg16386,16384,16385
STW %reg16386<kill>, 0, <fi#7>; mem:ST4[%a] GPRC:%reg16386
I am interesting in this method because it seems smart and different from
the compiler textbook. For understanding how it genera...
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 Sep 29
2
[LLVMdev] comparison pattern trouble
...= icmp eq i32 %3, 0
which compares the lowest bits of the 2 variables
ends up being compiled as
%reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
%reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
%reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
%reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
which just compares ALL BITS of the variables.
Any idea what is causing this and how this could be fixed?
2010 Sep 29
1
[LLVMdev] comparison pattern trouble - might be a bug in LLVM 2.8?
...the lowest bits of the 2 variables
>
>
> ends up being compiled as
>
>
> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>
>
> which just compares ALL BITS of the variables.
I also have a pattern:
def XORrrb : InstTCE<(outs I1Regs:$op3), (ins I...
2010 Sep 29
0
[LLVMdev] comparison pattern trouble - might be a bug in LLVM 2.8?
...s the lowest bits of the 2 variables
>> ends up being compiled as
>>
>> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
>> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
>> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>>
>> which just compares ALL BITS of the variables.
>
> I also have a pattern:
>
> def XORrrb : InstTCE<(out...
2010 Sep 30
4
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...f the 2 variables
>>> ends up being compiled as
>>>
>>> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
>>> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
>>> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>>> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>>>
>>> which just compares ALL BITS of the variables.
>> I also have a pattern:
>>
>> def XORrrb :...
2010 Nov 08
2
[LLVMdev] [LLVMDev] Register Allocation and copy instructions
...rm16 <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
BB#1: derived from LLVM BB %bb
Predecessors according to CFG: BB#0 BB#1
%reg16386<def> = PHI %reg16385, <BB#0>, %reg16394, <BB#1>;
GR16:%reg16386,16385,16394
%reg16387<def> = PHI %reg16384, <BB#0>, %reg16398, <BB#1>;
GR16:%reg16387,16384,16398
%reg16393<def> = MOV16ri 1; GR16:%reg16393
%reg16398<def> = COPY...
2010 Jul 28
0
[LLVMdev] Subregister coalescing
On Jul 28, 2010, at 12:25 PM, Carlos Sánchez de La Lama wrote:
> Which after register coalescing gets transformed into:
>
> 36 %reg16404:1<def> = LDWr %reg16384, 0; mem:LD4[<unknown>]
> 76 %reg16394<def> = LDWr %reg16386<kill>, 0; mem:LD4[<unknown>]
> 124 %reg16404<def> = INSERT_SUBREG %reg16404, %reg16394<kill>, 2
> 132 %reg16401<def> = LDWr %reg16390<kill>, 0; mem:LD4[<unknown>]
> 172 %reg16404<def> = INSERT_SUBREG %reg16404, %reg16401<kill>, 3
> 1...
2010 Oct 01
0
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...>>>> ends up being compiled as
>>>>
>>>> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
>>>> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
>>>> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>>>> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>>>>
>>>> which just compares ALL BITS of the variables.
>>> I also have a pattern:
>>>...
2010 Nov 24
1
[LLVMdev] Selecting BRCOND instead of BRCC
...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]
0x170e260: i16 = Register %reg16390 [ID=4]
0x170ed00: ch = seteq [ORD=1] [ID=9]
0x170dc60: i16,ch = CopyFromReg 0x16d5748, 0x170db60 [ORD=1] [ID=11]
0x16d5748: ch...
2010 Oct 01
2
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...t;> ends up being compiled as
>>>>>
>>>>> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
>>>>> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
>>>>> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>>>>> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>>>>>
>>>>> which just compares ALL BITS of the variables.
>>>> I also have a pattern:...
2010 Oct 04
2
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG
...; ends up being compiled as
>>>>>
>>>>> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
>>>>> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
>>>>> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>>>>> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>>>>>
>>>>> which just compares ALL BITS of the variables.
>>>> I also have a pattern:...
2010 Oct 02
1
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...> 0x2385070: i32 = Register %reg16385 [ID=7]
>>
>> 0x2384970:<multiple use>
>> 0x24b33f0: ch = CopyToReg 0x2536968, 0x2385070, 0x2384970 [ID=14]
>>
>> 0x2536968:<multiple use>
>> 0x24b35f0: i32 = Register %reg16386 [ID=8]
>>
>> 0x2384270:<multiple use>
>> 0x24b36f0: ch = CopyToReg 0x2536968, 0x24b35f0, 0x2384270 [ID=16]
>>
>> 0x24b40f0: ch = TokenFactor 0x2384e70, 0x24b33f0, 0x24b36f0 [ID=19]
>>
>> 0x2384270:<multiple use>
>&...
2010 Oct 04
0
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG
...g compiled as
>>>>>>
>>>>>> %reg16384<def> = LDWi <fi#-2>, 0; mem:LD4[FixedStack-2] I32Regs:%reg16384
>>>>>> %reg16385<def> = LDWi <fi#-1>, 0; mem:LD4[FixedStack-1] I32Regs:%reg16385
>>>>>> %reg16386<def> = COPY %reg16384; I32Regs:%reg16386,16384
>>>>>> %reg16390<def> = NErrb %reg16384, %reg16385; I1Regs:%reg16390 I32Regs:%reg16384,16385
>>>>>>
>>>>>> which just compares ALL BITS of the variables.
>>>>> I also...