Ok, I am tracking down some bugs in our AVX stuff and came upon
an interesting conundrum.
The MOVQ instruction (MOVPQIto64rr in X86Instr64bit.td) only takes
xmm registers. There is no ymm version since the xxm's are subregisters.
I need to be able to match 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
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; How does ${dst:subreg32} work? Can one do the same for sources? I don't see an references to "subreg" in the TableGen sources. I see it handled in the X86 AsmPrinter. Looks like it should work for sources too. Is it preferable to use the source modifier or write an EXTRACT_SUBREG pattern explicitly? -Dave
Hello, David> How does ${dst:subreg32} work?This is just modifier 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