search for: r600_reg32

...from LLVM BB %0     Live Ins: %T1_X %T1_Y %T1_Z %T1_W %vreg17<def> = COPY %T1_W; R600_TReg32:%vreg17 %vreg16<def> = COPY %T1_Z; R600_TReg32:%vreg16 %vreg15<def> = COPY %T1_Y; R600_TReg32:%vreg15 %vreg14<def> = COPY %T1_X; R600_TReg32:%vreg14 %vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 %vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; R600_Reg128:%vreg19 R600_TReg32:%vreg14 %vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 %vreg21:sel_x<def,read-undef> = COPY %vreg18<kill>; R600_Reg128:%vreg21 R600_Reg32:%vreg18 %vreg23<def> = COPY %vreg19&...

Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and vreg48 are joined. It's right. > > But joining the following copy > > 912B%vreg32:sel_x<def,read-undef> = COPY %vreg48:sel_x; R600...

...Ins: %T1_X %T1_Y %T1_Z %T1_W > %vreg17<def> = COPY %T1_W; R600_TReg32:%vreg17 > %vreg16<def> = COPY %T1_Z; R600_TReg32:%vreg16 > %vreg15<def> = COPY %T1_Y; R600_TReg32:%vreg15 > %vreg14<def> = COPY %T1_X; R600_TReg32:%vreg14 > %vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 > %vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; R600_Reg128:%vreg19 R600_TReg32:%vreg14 > %vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 > %vreg21:sel_x<def,read-undef> = COPY %vreg18<kill>; R600_Reg128:%vreg21 R600_Reg32:%vreg18 > %vreg23<def...

...he RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : // BEFORE LOOP ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 416B%vreg48<def> = COPY %vreg3<kill>; R600_Reg128:%vreg48,%vreg3 432B%vreg49<def> = COPY %vreg13<kill>; R600_Reg32:%vreg49,%vreg13    Successors according to CFG: BB#1 // LOOP CONDITION 464B%vreg5<def> = COPY %vreg47<kill>; R600_Reg32:%vreg5,%vr...

...so I'm posting my issue on the ML. Shader and print-before-all dump are given below. > > The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : > > // BEFORE LOOP > ... Some COPYs.... > 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2 > 416B%vreg48<def> = COPY %vreg3<kill>; R600_Reg128:%vreg48,%vreg3 > 432B%vreg49<def> = COPY %vreg13<kill>; R600_Reg32:%vreg49,%vreg13 > Successors according to CFG: BB#1 > > > // LOOP CONDITION > 464B%vreg5<def> = COPY %vreg47&...

...BB %0     Live Ins: %T1_W %T1_Z %T1_Y %T1_X %vreg3<def> = COPY %T1_X; R600_TReg32:%vreg3 %vreg2<def> = COPY %T1_Y; R600_TReg32:%vreg2 %vreg1<def> = COPY %T1_Z; R600_TReg32:%vreg1 %vreg0<def> = COPY %T1_W; R600_TReg32:%vreg0 RESERVE_REG 0 %vreg4<def> = FNEG_R600 %vreg3; R600_Reg32:%vreg4 R600_TReg32:%vreg3 %vreg5<def> = MOV_IMM_F32 0.000000e+00; R600_Reg32:%vreg5 %vreg6<def> = ADD 0, 0, 1, 0, 0, 0, %vreg4<kill>, 0, 0, 0, %vreg5, 0, 0, 0, 1, pred:%PRED_SEL_OFF, 0; R600_Reg32:%vreg6,%vreg4,%vreg5 %vreg7<def> = FNEG_R600 %vreg2; R600_Reg32:%vreg7 R600_TR...

...lt;kill>; R600_TReg32:%vreg16 register: %vreg16 +[32r,240r:0) 48B%vreg15<def> = COPY %T1_Y<kill>; R600_TReg32:%vreg15 register: %vreg15 +[48r,160r:0) 64B%vreg14<def> = COPY %T1_X<kill>; R600_TReg32:%vreg14 register: %vreg14 +[64r,96r:0) 80B%vreg18<def> = COPY %C1_X; R600_Reg32:%vreg18 register: %vreg18 +[80r,128r:0) 96B%vreg19:sel_x<def,read-undef> = COPY %vreg14<kill>; R600_Reg128:%vreg19 R600_TReg32:%vreg14 register: %vreg19 +[96r,144r:0) 112B%vreg2<def> = COPY %C1_Y; R600_Reg32:%vreg2 register: %vreg2 +[112r,400r:0) 128B%vreg21:sel_x<def,read-unde...

When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. If I look at the : %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 instructions ; it gets joined to : 928B%vreg34<def> = COPY %vreg48:sel_y;  when vreg6 and vreg48 are joined. It's right. But joining the following copy  912B%vreg32:sel_x<def,read-undef> = COPY %vreg48:sel_x; R600_Reg128:%vreg32,%vreg48 updates it to ...

...;t figure out how to modify > the instruction patterns to make this work. For example, I have the class: > > class R600_1OP <bits<32> inst, string opName, list<dag> pattern, > InstrItinClass itin = AnyALU> : > InstR600 <inst, > (outs R600_Reg32:$dst), > (ins R600_Reg32:$src, R600_Pred:$p, i32imm:$flags), > !strconcat(opName, " $dst, $src ($p)"), > pattern, > itin >> ; > > And an instruction def: > > def CEIL : R600_1OP < > 0x12, "CEIL", > [(...

...ate operands, but I can't figure out how to modify the instruction patterns to make this work. For example, I have the class: class R600_1OP <bits<32> inst, string opName, list<dag> pattern, InstrItinClass itin = AnyALU> : InstR600 <inst, (outs R600_Reg32:$dst), (ins R600_Reg32:$src, R600_Pred:$p, i32imm:$flags), !strconcat(opName, " $dst, $src ($p)"), pattern, itin >; And an instruction def: def CEIL : R600_1OP < 0x12, "CEIL", [(set R600_Reg32:$dst, (fceil R600_Reg32:$src))]...

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

...gt; the instruction patterns to make this work. For example, I have the > class: > > > > class R600_1OP <bits<32> inst, string opName, list<dag> pattern, > > InstrItinClass itin = AnyALU> : > > InstR600 <inst, > > (outs R600_Reg32:$dst), > > (ins R600_Reg32:$src, R600_Pred:$p, i32imm:$flags), > > !strconcat(opName, " $dst, $src ($p)"), > > pattern, > > itin > >> ; > > > > And an instruction def: > > > > def CEIL : R600_1OP...

...egister >> MachineOperands >> >> Tom, >> >> The generally accepted way of achieving this is to leave the built-in >> pattern on the instruction empty, and to use def : Pat constructs to >> provide the default values. >> >> def : Pat<(fceil R600_Reg32:$src), (CEIL R600_Reg32:$src, (i32 0))>; >> > [Villmow, Micah] Doing this for every instruction is unrealistic. Not particularly. There are backends already in existence that make heavy use of it. The key is that def : Pat constructs can take advantage of all of the same mechanisms...

...600 target and converting all the patterns to the new syntax, and I've come across a pattern that I'm unable to convert: class BitConvert <ValueType dt, ValueType st, RegisterClass rc> : Pat < (dt (bitconvert (st rc:$src0))), (dt rc:$src0) >; def : BitConvert <i32, f32, R600_Reg32>; In this example R600_Reg32 is a register that can hold f32 or i32 types, so bitconvert is a free operation. Any suggestions for how to re-work this pattern? Thanks, Tom

I have updated TableGen to support a new format for instruction selection patterns. Before: def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; After: def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input

...gt; > >> Tom, > >> > >> The generally accepted way of achieving this is to leave the built- > in > >> pattern on the instruction empty, and to use def : Pat constructs to > >> provide the default values. > >> > >> def : Pat<(fceil R600_Reg32:$src), (CEIL R600_Reg32:$src, (i32 0))>; > >> > > [Villmow, Micah] Doing this for every instruction is unrealistic. > > Not particularly. There are backends already in existence that make > heavy use of it. The key is that def : Pat constructs can take > advantage o...

...egisterCoalescer pass does not preserve TargetFlag in the JoinCopy() member function. For instance, here is some output of the regalloc pass (TF=2 corresponds to a Neg TargetFlag) : 352B    %vreg20:sel_x<def,undef> = COPY %vreg16<kill>[TF=2], %vreg20<imp-def>; R600_Reg128:%vreg20 R600_Reg32:%vreg16     Considering merging %vreg16 with %vreg20:sel_x     Cross-class to R600_Reg128.         RHS = %vreg16 = [304r,352r:0)  0 at 304r         LHS = %vreg20 = [352r,400r:0)  0 at 352r         updated: 304B    %vreg20:sel_x<def,undef> = MUL %vreg3:sel_x<kill>, %vreg15; R600_Reg128:%...

Hello, I have a compiler in LLVM 2.9 for the KCPM3 processor. I'd like to create a subtarget for the new cpu version called KCPSM6. Besides a couple of new instructions which are not important at the moment, the KCPSM6 cpu has different instruction opcodes. Semantically the instructions are the same, hence I'd like to keep all the lowering and pattern matching stuff unmodified For