search for: palignr

...n ssse3+ targets for the cases where zeros > are being shifted in? It avoids the need for a zero register (although they > aren't as good for memory folding). I'm curious, how important is this? This lowering has always seemed deeply magical and unlikely to be necessary in practice. palignr at least allows blending. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/a5156662/attachment.html>

...://reviews.llvm.org/rL229069 there was no Intrinsic::x86_sse2_psrl_dq any more, then how to migrate: Function *F = Intrinsic::getDeclaration(TheModule, Intrinsic::x86_sse2_psrl_dq); Result = Builder.CreateCall(F, ArrayRef<Value *>(&Ops[0], 2), "palignr"); And clang v3.9 migrated X86::BI__builtin_ia32_palignr128 like this https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CGBuiltin.cpp#L7629 just ignored the if (shiftVal < 32) condition? https://github.com/llvm-mirror/clang/blob/release_33/lib/CodeGen/CGBuiltin.cpp#L2642 Pl...

...xmm0 > = xmm0[0,2],xmm_mem_1[1,2] > > > I also see a lot of somewhat neutral (focusing on Haswell for now) > domain changes such as (xmm5 and 0 are initially integers, and are > dead after the store): > vpshufd $-0x5c, %xmm0, %xmm0 ## xmm0 = xmm0[0,1,2,2] > vpalignr $0xc, %xmm0, %xmm5, %xmm0 ## xmm0 > = xmm0[12,13,14,15],xmm5[0,1,2,3,4,5,6,7,8,9,10,11] > vmovdqu %xmm0, 0x20(%rax) > turning into: > vshufps $0x2, %xmm5, %xmm0, %xmm0 ## xmm0 = xmm0[2,0],xmm5[0,0] > vshufps $-0x68, %xmm5, %xmm0, %xmm0 ## xmm0 = xmm...

...t;> >>> I also see a lot of somewhat neutral (focusing on Haswell for now) >>> domain changes such as (xmm5 and 0 are initially integers, and are >>> dead after the store): >>> vpshufd $-0x5c, %xmm0, %xmm0 ## xmm0 = xmm0[0,1,2,2] >>> vpalignr $0xc, %xmm0, %xmm5, %xmm0 ## xmm0 >>> = xmm0[12,13,14,15],xmm5[0,1,2,3,4,5,6,7,8,9,10,11] >>> vmovdqu %xmm0, 0x20(%rax) >>> turning into: >>> vshufps $0x2, %xmm5, %xmm0, %xmm0 ## xmm0 = xmm0[2,0],xmm5[0,0] >>> vshufps $...

...m_1[1,2] >> >> >> I also see a lot of somewhat neutral (focusing on Haswell for now) >> domain changes such as (xmm5 and 0 are initially integers, and are >> dead after the store): >> vpshufd $-0x5c, %xmm0, %xmm0 ## xmm0 = xmm0[0,1,2,2] >> vpalignr $0xc, %xmm0, %xmm5, %xmm0 ## xmm0 >> = xmm0[12,13,14,15],xmm5[0,1,2,3,4,5,6,7,8,9,10,11] >> vmovdqu %xmm0, 0x20(%rax) >> turning into: >> vshufps $0x2, %xmm5, %xmm0, %xmm0 ## xmm0 = xmm0[2,0],xmm5[0,0] >> vshufps $-0x68, %xmm5, %xmm0,...

...gt; I also see a lot of somewhat neutral (focusing on Haswell for now) >>>> domain changes such as (xmm5 and 0 are initially integers, and are >>>> dead after the store): >>>> vpshufd $-0x5c, %xmm0, %xmm0 ## xmm0 = xmm0[0,1,2,2] >>>> vpalignr $0xc, %xmm0, %xmm5, %xmm0 ## xmm0 >>>> = xmm0[12,13,14,15],xmm5[0,1,2,3,4,5,6,7,8,9,10,11] >>>> vmovdqu %xmm0, 0x20(%rax) >>>> turning into: >>>> vshufps $0x2, %xmm5, %xmm0, %xmm0 ## xmm0 = >>>> xmm0[2,0],xmm5[0,0]...

On Sat, Sep 20, 2014 at 7:12 AM, Simon Pilgrim <llvm-dev at redking.me.uk> wrote: > Hi Andrea / Chandler / Quentin, > > If AVX is available I would expect the vpermilps/vpermilpd instruction to > be used for all float/double single vector shuffles, especially as it can > deal with the folded load case as well - this would avoid the integer/float > execution domain

...c_methods.m Clang :: PCH/objc_property.m Clang :: PCH/objcxx-ivar-class.mm Clang :: PCH/pragma-diag-section.cpp Clang :: PCH/reinclude.cpp Clang :: PCH/struct.c Clang :: PCH/typo.m Clang :: PCH/va_arg.cpp Clang :: Sema/stdcall-fastcall.c Clang :: Sema/x86-builtin-palignr.c Clang :: SemaCXX/attr-regparm.cpp Expected Passes : 8116 Expected Failures : 68 Unsupported Tests : 542 Unexpected Failures: 39

...Zeroable, Subtarget, DAG)) return Shift; // Try to use VALIGN. if (SDValue Rotate = lowerVectorShuffleAsRotate(DL, MVT::v32i64, V1, V2, Mask, Subtarget, DAG)) return Rotate; // Try to use PALIGNR. if (SDValue Rotate = lowerVectorShuffleAsByteRotate(DL, MVT::v32i64, V1, V2, Mask, Subtarget, DAG)) return Rotate; if (SDValue Unpck = lowerVectorShuffleWithUNPCK(DL, MVT::v32i64, Mask, V1, V2, DAG)) return Unpck; // If...

Greetings LLVM hackers and x86 vector shufflers! I would like to flip on another chunk of the new vector shuffling, specifically the logic to mark ~all shuffles as "legal". This can be tested today with the flag "-x86-experimental-vector-shuffle-legality". I would essentially like to make this the default (by removing the "false" path). Doing this will allow me to

On Tue, Sep 9, 2014 at 11:39 PM, Chandler Carruth <chandlerc at google.com> wrote: > Awesome, thanks for all the information! > > See below: > > On Tue, Sep 9, 2014 at 6:13 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> > wrote: >> >> You have already mentioned how the new shuffle lowering is missing >> some features; for example, you explicitly