search for: extract_subreg

Hi, I was wondering if there is a way to specify macros to help shorten rewriting patterns like these: def : Pat <(v4i8 (mul (v4i8 IntRegs:$a), (v4i8 IntRegs:$b))), (v4i8 (VTRUNEHB (v4i16 (VTRUNEWH (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), subreg_hireg)), (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$b))), subreg_hireg)))), (v2i32 (VMPYH (v2i16 (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), subreg_loreg)), (v2i16 (EXTRACT_S...

...;ve got the following problem in the X86 selector generated by TableGen: llvm/lib/Target/X86/X86GenDAGISel.inc:91821: error: duplicate case value llvm/lib/Target/X86/X86GenDAGISel.inc:91442: error: previously used here This seems to happen because of a pattern I added for VEXTRACTF128 which uses extract_subreg: [(set DSTREGCLASS:$dst, (DSTTYPE (extract_subreg (vector_shuffle (SRCTYPE undef), (SRCTYPE SRCREGCLASS:$src1), VEXTRACTF128_shuffle_mask:$src2), x86_subreg_128bit)))], def x86_subreg_128bit...

...a couple of 64-bit load/store instructions which use two neighboring regs at once, which i'm trying to employ using virtual regs with subs. For example, it I want to move one 64-bit virtual reg to another, I'm trying to use the following pattern: def LoReg: OutPatFrag<(ops node:$Rd), (EXTRACT_SUBREG (i64 $Rd), isub_lo)>; def HiReg: OutPatFrag<(ops node:$Rd), (EXTRACT_SUBREG (i64 $Rd), isub_hi)>; def MOVi64rr : Pat<(set GPR64:$Rd, GPR64:$Rn), (REG_SEQUENCE GPR64, (MOVi32rr (HiReg GPR64:$Rn)), isub_hi, (MOVi32rr (LoReg GPR64:$Rn)), isub_lo)>; isub_hi and isub_...

...the X86 selector generated by > TableGen: > > llvm/lib/Target/X86/X86GenDAGISel.inc:91821: error: duplicate case value > llvm/lib/Target/X86/X86GenDAGISel.inc:91442: error: previously used here > > This seems to happen because of a pattern I added for VEXTRACTF128 which > uses extract_subreg: > > [(set DSTREGCLASS:$dst, > (DSTTYPE (extract_subreg > (vector_shuffle > (SRCTYPE undef), > (SRCTYPE SRCREGCLASS:$src1), > VEXTRACTF128_shuffle_mask:$src2), > x86_subr...

On Thursday 03 December 2009 13:43, David Greene wrote: > Whoops, I forgot to fill in types: > > (outs VR128:$dst), (ins VR129:$src1, i32i8imm:$src2) > > [(set DSTREGCLASS:$dst, > (v4f32 (extract_subreg > (vector_shuffle > (v8f32 undef), > (v8f32 SRCREGCLASS:$src1), > VEXTRACTF128_shuffle_mask:$src2), > x86_subreg_128bit)))], Well, it's conflicting with the hard-coded case stateme...

...there is a way to specify macros to help shorten > rewriting patterns like these: > > def : Pat <(v4i8 (mul (v4i8 IntRegs:$a), (v4i8 IntRegs:$b))), > (v4i8 > (VTRUNEHB > (v4i16 > (VTRUNEWH > (v2i32 > (VMPYH > (v2i16 > (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), > subreg_hireg)), > (v2i16 > (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$b))), > subreg_hireg)))), > (v2i32 > (VMPYH > (v2i16 > (EXTRACT_SUBREG (v4i16 (VSXTBH (v4i8 IntRegs:$a))), > subre...

I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. The COPY instruction handles subreg operations with less redundancy: %reg1045<def> = EXTRACT_SUBREG %reg1044<kill>, 4 %...

On Jun 15, 2010, at 2:48 PM, Jakob Stoklund Olesen wrote: > I am considering adding a new target independent codegen-only COPY instruction to our MachineInstr representation. It would be used to replace INSERT_SUBREG, EXTRACT_SUBREG, and virtual register copies after instruction selection. Selection DAG still needs {INSERT,EXTRACT}_SUBREG, but they would not appear as MachineInstrs any longer. > > The COPY instruction handles subreg operations with less redundancy: > > %reg1045<def> = EXTRACT_SUBREG %reg10...

...tch a vector element extract of element 0 on a v4i64 vector. Obviously this is not a legal operation even with AVX because MOVQ only operates on xmms. So I can mark it as not legal but how should it be lowered? I can't bitcast to a v2i64 because the vector sizes are different. I could do an extract_subreg and then write a pattern to match that to MOVQ. Anyone have other thoughts? -Dave

...ut not any longer. That is all derived from the instruction descriptions now. As far as I can tell, all sub-register operations involving sub_ss and sub_sd can simply be replaced with COPY_TO_REGCLASS: def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), (VMOVSDrr VR128:$src1, (EXTRACT_SUBREG (v4i32 VR128:$src2), sub_sd))>; Becomes: def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), (VMOVSDrr VR128:$src1, (COPY_TO_REGCLASS VR128:$src2, FR64))>; By eliminating these indexes, I can remove the 'CompositeIn...

...esen at apple.com> writes: > >> As far as I can tell, all sub-register operations involving sub_ss and >> sub_sd can simply be replaced with COPY_TO_REGCLASS: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1, (EXTRACT_SUBREG (v4i32 VR128:$src2), >> sub_sd))>; >> >> Becomes: >> >> def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), >> (VMOVSDrr VR128:$src1, (COPY_TO_REGCLASS VR128:$src2, FR64))>; > > A...

...or ldop> : Pat<(i32 (add (mulB<ldop> GPR64sp:$Rn, GPR64sp:$Rm, (i64 3)), (add (mulB<ldop> GPR64sp:$Rn, GPR64sp:$Rm, (i64 2)), (add (mulB<ldop> GPR64sp:$Rn, GPR64sp:$Rm, (i64 1)), (mulBz<ldop> GPR64sp:$Rn, GPR64sp:$Rm))))), (EXTRACT_SUBREG (i64 (DOT (DUPv2i32gpr WZR), (v8i8 (LD1Onev8b GPR64sp:$Rn)), (v8i8 (LD1Onev8b GPR64sp:$Rm)))), sub_32)>, Requires<[HasDotProd]>; def : DotProductI32<SDOTv8i8, sextloadi8>; def : DotProductI32<UDOTv8i8, zextloadi8>; Then when...

...a subregister for the address (which is zero-extended, effectively ignoring the metadata bits). As a side note, GCC does emit the second snippet as expected. Looking at the TableGen files I found two problems: 1. The AND of the address with 0xffffffff is replaced with SUBREG_TO_REG(MOV32rr (EXTRACT_SUBREG ...)) in lib/Target/X86/X86InstrCompiler.td (line 1326). That MOV32rr emits an explicit mov instruction later. I think I need to replace this with (i32 (EXTRACT_SUBREG ...)) to get rid of the mov, but that produces a 32-bit value, which leads me to the next, more general problem: 2. The x86 ba...

On Tuesday 24 November 2009 12:57, David Greene wrote: > So I can mark it as not legal but how should it be lowered? I can't > bitcast to a v2i64 because the vector sizes are different. I could > do an extract_subreg and then write a pattern to match that to MOVQ. What does this mean? def MOVSX16rr8 : I<0xBE, MRMSrcReg, (outs GR16:$dst), (ins GR8 :$src), "movs{bl|x}\t{$src, ${dst:subreg32}|${dst:subreg32}, $src}", [(set GR16:$dst, (sext GR8:$src))]>, TB;...

...s out of order: Starting with this: 0x10015677970: i32 = Register %CR0 0x10015679080: i32 = TargetConstant<3> ... 0x10015671b80: i32 = TargetConstant<1> 0x10015678d80: i32,glue = ANDIo 0x100156746c0, 0x10015671b80 [ORD=49] 0x100156749c0: i1 = EXTRACT_SUBREG 0x10015677970, 0x10015679080, 0x10015678d80:1 [ORD=49] 0x10015671d80: ch = CopyToReg 0x100156463c8, 0x10015677c70, 0x100156749c0 [ORD=49] ... the two glued nodes are put together in the same SU: SU(2): 0x100156749c0: i1 = EXTRACT_SUBREG 0x10015677970, 0x10015679080, 0x10015678d80:1 [ORD=49]...

...difier provided to asmprinting code. Here, it seems, 16 bit register is passed to asmprinter, but it sees modifier and grabs 32-bit superreg. > Can one do the same for sources? Yes, this is just modifier for printing, nothing more... > Is it preferable to use the source modifier or write an EXTRACT_SUBREG > pattern explicitly? It depends what you're want to do. But I guess you need to model subreg access properly... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...certainly mentioned more than just in the code above. > As far as I can tell, all sub-register operations involving sub_ss and > sub_sd can simply be replaced with COPY_TO_REGCLASS: > > def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), > (VMOVSDrr VR128:$src1, (EXTRACT_SUBREG (v4i32 VR128:$src2), > sub_sd))>; > > Becomes: > > def : Pat<(v4i32 (X86Movsd VR128:$src1, VR128:$src2)), > (VMOVSDrr VR128:$src1, (COPY_TO_REGCLASS VR128:$src2, FR64))>; A few questions: Will COPY_TO_REGC...

...== badness so I'd tried to add it to the pattern I wanted to disable. Thanks for the pointer. > 1. Treat these instructions as cross register class copies. The src > and dst classes are different (VR128 and FR32) but "compatible". This seems reasonable. > 2. Model it as extract_subreg which coalescer can eliminate. > > #2 is conceptually correct. The problem is 128 bit XMM0 is the same > register as 32 bit (or 64 bit) XMM0. So it's not possible to define > the super-register / sub-register relationship. I'm not seeing how this is "conceptually correct.&...

...ot to expand i64 to two i32. 2. I guess I need a special pseudo instruction to move between GPR32 and GPR64. How to move R0, R1 to T1( R2, R3 pair). and don't convert two i32 to i64? Could I use MyTargetInstrInfo::copyRegToReg() to handle this logic issue? 3. Maybe I can study INSERT_SUBREG/EXTRACT_SUBREG at X86 porting file. I will do some research more deeply. I think the best way is that TableGen has register pair TypeProfile feature. :( But I find i64 data will not be ex --- 09年2月20日，周五, Evan Cheng <echeng at apple.com> 写道： 发件人: Evan Cheng <echeng at apple.com> 主题: Re: [LLVMde...

...h is zero-extended, effectively > ignoring the metadata bits). As a side note, GCC does emit the second > snippet as expected. > > > Looking at the TableGen files I found two problems: > > 1. The AND of the address with 0xffffffff is replaced with > SUBREG_TO_REG(MOV32rr (EXTRACT_SUBREG ...)) in > lib/Target/X86/X86InstrCompiler.td (line 1326). That MOV32rr emits an > explicit mov instruction later. I think I need to replace this with > (i32 (EXTRACT_SUBREG ...)) to get rid of the mov, but that produces a > 32-bit value, which leads me to the next, more general pro...