search for: reg16385

...xt i8 %data to i32 %1 = zext i16 %crc to i32 %2 = xor i32 %1, %0 %3 = and i32 %2, 1 %4 = 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. A...

...definition cannot be mapped to machine code. For instance I come across (1) and I reduce it to (2). However a copy instruction cannot move from EDX to CX. What mechanics in LLVM will tell me that I cannot make this move during register allocation, or how can I tell from (1) that I cannot execute %reg16385<def> = COPY %reg16390. Furthermore, how should I handle this case. 1: # Machine code for function test5: Frame Objects: fi#-2: size=2, align=4, fixed, at location [SP+8] fi#-1: size=2, align=8, fixed, at location [SP+4] Function Live Outs: %AX BB#0: derived from LLVM BB %entry %...

Hi, I want to know what is the type or size of a virtual register in a Machineinstr::MachineOperand (If this MachineOperand is a register). For example, what is the size of reg16385 in the following MachineInstr. I know now in the llvm bitcode, the type of a Instruction could be obtained from the Value::GetType(), but what is the counterpart in MachineInstr (not derived from class Value)? %reg16385<def> = MOV32rm <fi#0>, 1, %reg0, 0, %reg0; mem:LD4[%x_addr] GR32:...

...r i32 %1, %0 > %3 = and i32 %2, 1 > %4 = 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 BIT...

...on 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<imp-def,dead>; IntRegs:%reg16388,16384,16385 SKIPC...

...cannot be mapped to machine code. > > For instance I come across (1) and I reduce it to (2). However a copy instruction cannot move from EDX to CX. What mechanics in LLVM will tell me that I cannot make this move during register allocation, or how can I tell from (1) that I cannot execute %reg16385<def> = COPY %reg16390. Furthermore, how should 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<ki...

...e kill flag? This code below is just an example from test\CodeGen\X86\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB %entry %reg16385<def> = MOV32rm <fi#-2>, 1, %reg0, 0, %reg0; mem:LD4[FixedStack-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 %r...

...the next operation, in this case we're returning the result. This gives me this code before instr sel: # Machine code for function foo: Function Live Ins: %R25R24 in reg%16384, %R23R22 in reg%16385 Function Live Outs: %R25R24 BB#0: derived from LLVM BB %entry Live Ins: %R25R24 %R23R22 %reg16385<def> = COPY %R23R22; WDREGS:%reg16385 // 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 WDRE...

...2 %1, %0 >> %3 = and i32 %2, 1 >> %4 = 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...

...i32 %2, 1 >>> %4 = 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 >>> >>> whic...

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

...%4 = 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 >>>> >&g...

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

There are a lot of load/store instructions for 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...

...; >>>>>> 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 >>&g...

...i16,ch = CopyFromReg 0x16d5748, 0x170de60 [ID=12] 0x16d5748: ch = EntryToken [ORD=1] [ID=0] 0x170de60: i16 = Register %reg16388 [ID=2] 0x170e760: ch = 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] 0x1...

...> 0x2384d70: i32 = Register %reg16384 [ID=6] >> >> 0x2384270:<multiple use> >> 0x2384e70: ch = CopyToReg 0x2536968, 0x2384d70, 0x2384270 [ID=17] >> >> 0x2536968:<multiple use> >> 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] >> >> 0x2384...

Hello Per, > The CMPrr instruction is moved down to after the PHI node. My guess is that > the 'dead' in CFR<imp-def,dead> is to blame, but I can't see what I'm doing > differently from MSP430/sparc that makes this not work. Any help GREATLY > appreciated! It seems like no use of CFR after CMP, indeed. How condbranches on your platform look like (patterns, etc.)

But in the first version it's used on the next row: %reg16388<def> = CMPrr %reg16384, %reg16385, %CFR<imp-def,dead>; IntRegs:%reg16388,16384,16385 SKIPCOND 1, *%CFR<imp-use>* Or doesn't that count? Following are patters for cmp and skipcond: def cmpcc : SDNode<"CSISD::CMP", SDTIntBinOp, [SDNPOutFlag]>; let Defs = [CFR] in { def CMPrr : InstCS<(out...

...; <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 %reg16384<kill> 64L %reg16389<def>, %CPSR<def,dead> = tEOR %reg16389, %reg16386<kill>, pred:14, pred:%reg0 76L...