search for: scalar_to_vector

On Thursday 02 October 2008 11:37, David Greene wrote: > I'll try ot write a small example and send it in a bit. Ok, here's what I'm trying to do: let AddedComplexity = 40 in { def : Pat<(v2f64 (vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr: $src1))), (v2f64 (scalar_to_vector (loadf64 addr: $src2))), SHUFP_shuffle_mask:$sm)), (SHUFPDrri (v2f64 (MOVSD2PDrm addr:$src1)), (v2f64 (MOVSD2PDrm addr:$src2)),...

...selection know how to clean up > nodes that become dead during selection, but my guess is that > it's missing some cases. Ok, as far as I can tell, here's what's happening. I have the following pattern: let AddedComplexity = 40 in { def : Pat<(v2f64 (vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr: $src1))), (v2f64 (scalar_to_vector (loadf64 addr: $src2))), SHUFP_shuffle_mask:$sm)), (SHUFPDrri (v2f64 (MOVSD2PDrm addr:$src1)), (v2f64 (MOVSD2PDrm addr:$src2)),...

.... Here i need to define vector load and stores for 64 i32 elements. so in x86instrinfo.td i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))], IIC_MOV_MEM>, EVEX; def VMOV_256B_MR : I<0x7F, MRMDestMem, (outs), (ins i32mem:$dst, VR2048:$src), "vmov_256B_mr\t{$src, $dst|$dst, $src}", [(store (i32 (bitconvert VR2048:$src)), addr:$dst)], IIC_...

I'm debugging some X86 patterns and I want to understand the debug dumps from isel better. Here's some example output: 0x391bc40: i64,ch = load 0x3922c50, 0x391b8d0, 0x38dc530 <0x39053e0:0> <sext i32> alignment=4 srcLineNum= 10 0x3922c50: <multiple use> 0x391bc40: <multiple use> 0x3856ab0: <multiple use> 0x3914520: i64 =

...h", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, > (DSTTYPE (bitconvert > (v2f64 (scalar_to_vector > (loadf64 addr:$src2))))))))], > // rr Pat > [], > // rm Pat > [[(DSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))), > (MNEMONIC SRCREGCLASS:$src1, addr:$src2)], >...

...some of the patterns in X86InstrX86-64.td are wrong. Specifically: def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins i64mem:$src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(set VR128:$dst, (v2i64 (scalar_to_vector (loadi64 addr:$src))))]>; def MOVPQIto64mr : RPDI<0x7E, MRMDestMem, (outs), (ins i64mem:$dst, VR128: $src), "mov{d|q}\t{$src, $dst|$dst, $src}", [(store (i64 (vector_extract (v2i64 VR128:$src),...

...nodes that become dead during selection, but my guess is that >> it's missing some cases. > > Ok, as far as I can tell, here's what's happening. > > I have the following pattern: > > let AddedComplexity = 40 in { > def : Pat<(v2f64 (vector_shuffle (v2f64 (scalar_to_vector (loadf64 > addr: > $src1))), > (v2f64 (scalar_to_vector (loadf64 > addr: > $src2))), > SHUFP_shuffle_mask:$sm)), > (SHUFPDrri (v2f64 (MOVSD2PDrm addr:$src1)), > (v2f64 (M...

I have the following selection DAG: SelectionDAG has 9 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t16: i32,ch = load<LD1[%ptr](tbaa=<0x10023c9f448>), anyext from i8> t0, t2, undef:i64 t15: v16i8 = BUILD_VECTOR t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16, t16 t11: ch,glue = CopyToReg t0, Register:v16i8 %V2, t15

...i8> %2 ) nounwind readnone ; <<2 x i64>>:6 [#uses=1] ret <4 x i32> %3 } declare <4 x i32> @llvm.x86.sse41.pmovsxbd(<16 x i8>) nounwind readnone I think the issue is that the pattern for the memory operand of pmovsxbd isn't flexible enough to see through the scalar_to_vector step. -Eli

On Thursday 02 October 2008 12:42, David Greene wrote: > But let's say you _could_ write such a pattern (because I can). The input > DAG looks like this: > > 0x391a220: <multiple use> > 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 > 0x391ac10: <multiple use> > 0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10 > 0x3927b10: <multiple use> > 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, > 0x3927b10<0,2> srcLine...

On Fri, October 3, 2008 9:10 am, David Greene wrote: > On Thursday 02 October 2008 19:32, Dan Gohman wrote: > >> Looking at your dump() output above, it looks like the pre-selection >> loads have multiple uses, so even though you've managed to match a >> larger pattern that incorporates them, they still need to exist to >> satisfy some other users. > > Yes,

...only< 0x16, "movh", undef, 0, // rr [(undef)], // rm [(set DSTREGCLASS:$dst, (DSTTYPE (movlhps SRCREGCLASS:$src1, (DSTTYPE (bitconvert (v2f64 (scalar_to_vector (loadf64 addr:$src2))))))))], // rr Pat [], // rm Pat [[(DSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))), (MNEMONIC SRCREGCLASS:$src1, addr:$src2)], [(INTDSTTYPE (movl...

I've run into a situation in isel where it seems like the selector is generating a cycle in the DAG. I have something like this: 0x215f140: v2f64 = llvm.x86.sse2.min.sd 0x215efd0, 0x21606d0, 0x215eb80 [0] 0x215efd0: i64 = Constant <647> [0] 0x21606d0: v2f64 = scalar_to_vector 0x213b8f0 [0] 0x213b8f0: f64,ch = load 0x213b780, 0x213aa90, 0x213b610 <0x2113690:0> alignment=8 [0] 0x213b780: ch = Prefetch 0x213aee0:1, 0x213b1c0, 0x213b330, 0x213b4a0 [1] 0x213aee0: f64,ch = load 0x213a720, 0x213ac00, 0x213b610 <0x215ace8:0> alignment=8 [0] 0x2...

On Thursday 02 October 2008 19:32, Dan Gohman wrote: > Looking at your dump() output above, it looks like the pre-selection > loads have multiple uses, so even though you've managed to match a > larger pattern that incorporates them, they still need to exist to > satisfy some other users. Yes, I looked at that too. It looks like these other uses end up being chains to

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

Hi all, I was wondering how to use variations of intrinsic functions that take a memory operand. Take for example the SSE4.1 pmovsxbd instruction. One variant takes two XMM registers, while another has a 32-bit memory location as source operand. The latter is quite interesting if you know you're reading from memory anyway, and if it's not 16-byte aligned. It looks like LLVM's

...wrote: > On Thursday 02 October 2008 12:42, David Greene wrote: > >> But let's say you _could_ write such a pattern (because I can). >> The input >> DAG looks like this: >> >> 0x391a220: <multiple use> >> 0x391c970: v2f64 = scalar_to_vector 0x391a220 srcLineNum= 10 >> 0x391ac10: <multiple use> >> 0x391c8b0: v2f64 = scalar_to_vector 0x391ac10 srcLineNum= 10 >> 0x3927b10: <multiple use> >> 0x3923100: v2f64 = vector_shuffle 0x391c970, 0x391c8b0, >> 0x3927b10&lt...

...> <index>). And I've written a simple test for it. Basically I just want to see if it works. However When I run it through llc I get a following error: LLVM ERROR: Cannot select: 0x2ac3180: v4i32 = vector_shuffle 0x2ac2f70, 0x2ac3078<0,4,u,u> [ORD=3] [ID=10] 0x2ac2f70: v4i32 = scalar_to_vector 0x2ac38b8 [ORD=3] [ID=8] 0x2ac38b8: i32,ch = CopyFromReg 0x2a9c8b0, 0x2ac37b0 [ORD=1] [ID=5] 0x2ac37b0: i32 = Register %vreg4 [ID=1] 0x2ac3078: v4i32 = scalar_to_vector 0x2ac3ac8 [ORD=3] [ID=9] 0x2ac3ac8: i32,ch = CopyFromReg 0x2a9c8b0, 0x2ac39c0 [ORD=1] [ID=6] 0x2ac39c0: i32...

...// rr >> [(undef)], >> // rm >> [(set DSTREGCLASS:$dst, >> (DSTTYPE (movlhps SRCREGCLASS:$src1, >> (DSTTYPE (bitconvert >> (v2f64 (scalar_to_vector >> (loadf64 addr:$src2))))))))], >> // rr Pat >> [], >> // rm Pat >> [[(DSTTYPE (movlhps SRCREGCLASS:$src1, (load addr:$src2))), >> (MNEMONIC SRCREGCLASS:$sr...

Ok, this is really complicated. I need some TableGen experts to help here. I need a little help doing a final bit of tblgen hacking. I've hacked tblgen to handle patterns like this: let AddedComplexity = 40 in { def : Pat<(vector_shuffle (v2f64 (scalar_to_vector (loadf64 addr:$src1))), (v2f64 (scalar_to_vector (loadf64 addr:$src2))), SHUFP_shuffle_mask:$sm), (SHUFPDrri (MOVSD2PDrm addr:$src1), (MOVSD2PDrm addr:$src2), SHUFP_shuffle_mask:$sm)>, Requ...