search for: reg16386

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