search for: vinsertf128

...en: In VEXTRACTF128_256mri: Type inference contradiction found in node vector_shuffle! Well, it's right! So how do I express this kind of thing? Since LLVM 2.5 shufflevector supports creating a vector of a difference size than the inputs. Which is exactly what we need for VEXTRACTF128 and VINSERTF128. -Dave

...able. If you run in AVX mode and call lookup with VEXTRACTF128rr you fail with assertion. - Elena From: Craig Topper [mailto:craig.topper at gmail.com] Sent: Wednesday, January 04, 2012 19:32 To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Execution domain for VEXTRACTF128/VINSERTF128 What domain do you think they should have? They are floating point, but not technically double or single. The domain fix pass will treat them as either anyway as I've put them in the table for both single and double. >From X86InstrInfo.cpp { X86::VEXTRACTF128mr, X86::VEXTRACTF128mr, X86...

...r single. The domain fix pass will treat them as either anyway as I've put them in the table for both single and double. >From X86InstrInfo.cpp { X86::VEXTRACTF128mr, X86::VEXTRACTF128mr, X86::VEXTRACTI128mr }, { X86::VEXTRACTF128rr, X86::VEXTRACTF128rr, X86::VEXTRACTI128rr }, { X86::VINSERTF128rm, X86::VINSERTF128rm, X86::VINSERTI128rm }, { X86::VINSERTF128rr, X86::VINSERTF128rr, X86::VINSERTI128rr }, { X86::VPERM2F128rm, X86::VPERM2F128rm, X86::VPERM2I128rm }, { X86::VPERM2F128rr, X86::VPERM2F128rr, X86::VPERM2I128rr } On Wed, Jan 4, 2012 at 4:32 AM, Demikhovsky, Ele...

Hi, I noticed, that execution domain is set to SSEPackedSingle for these instructions. Looks like a bug. let neverHasSideEffects = 1, ExeDomain = SSEPackedSingle in { def VEXTRACTF128rr : AVXAIi8<0x19, MRMDestReg, (outs VR128:$dst), - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain

Hello, LLVM generates two additional instructions for 128->256 bit typecasts (e.g. _mm256_castsi128_si256()) to clear out the upper 128 bits of YMM register corresponding to source XMM register. vxorps xmm2,xmm2,xmm2 vinsertf128 ymm0,ymm2,xmm0,0x0 Most of the industry-standard C/C++ compilers (GCC, Intel's compiler, Visual Studio compiler) don't generate any extra moves for 128-bit->256-bit typecast intrinsics. None of these compilers zero-extend the upper 128 bits of the 256-bit YMM register. Intel's do...

I'm working on some of the AVX insert/extract instructions. They're stupid. They do not operate on ymm registers, meaning we have to use VINSERTF128/VEXTRACTF128 and then do the real operation. Anyway, I'm looking at how INSERTPS and friends work and noticed that there are special SelectionDAG nodes for them and corresponding TableGen dag operators (X86insrtps, for example). What's the reason for using special dag operators as opposed...

...6mri: Type inference contradiction found in node > vector_shuffle! > > Well, it's right!  So how do I express this kind of thing?  Since LLVM 2.5 > shufflevector supports creating a vector of a difference size than the > inputs.  Which is exactly what we need for VEXTRACTF128 and VINSERTF128. Perhaps EXTRACT_SUBVECTOR would be more appropriate here? -Eli

...December 2009 16:51, Eli Friedman wrote: > On Wed, Dec 2, 2009 at 2:44 PM, David Greene <dag at cray.com> wrote: > > I'm working on some of the AVX insert/extract instructions.  They're > > stupid.  They do not operate on ymm registers, meaning we have to > > use VINSERTF128/VEXTRACTF128 and then do the real operation. > > > > Anyway, I'm looking at how INSERTPS and friends work and noticed that > > there are special SelectionDAG nodes for them and corresponding TableGen > > dag operators (X86insrtps, for example). > > > > What...

On Wed, Dec 2, 2009 at 2:44 PM, David Greene <dag at cray.com> wrote: > I'm working on some of the AVX insert/extract instructions.  They're > stupid.  They do not operate on ymm registers, meaning we have to > use VINSERTF128/VEXTRACTF128 and then do the real operation. > > Anyway, I'm looking at how INSERTPS and friends work and noticed that > there are special SelectionDAG nodes for them and corresponding TableGen > dag operators (X86insrtps, for example). > > What's the reason for using spec...

...6:51, Eli Friedman wrote: >> On Wed, Dec 2, 2009 at 2:44 PM, David Greene <dag at cray.com> wrote: >> > I'm working on some of the AVX insert/extract instructions.  They're >> > stupid.  They do not operate on ymm registers, meaning we have to >> > use VINSERTF128/VEXTRACTF128 and then do the real operation. >> > >> > Anyway, I'm looking at how INSERTPS and friends work and noticed that >> > there are special SelectionDAG nodes for them and corresponding TableGen >> > dag operators (X86insrtps, for example). >> &...

On Dec 2, 2009, at 3:46 PM, David Greene wrote: > Well, it's right! So how do I express this kind of thing? Since LLVM 2.5 > shufflevector supports creating a vector of a difference size than the > inputs. Which is exactly what we need for VEXTRACTF128 and VINSERTF128. I think the SelectionDAG vector_shuffle node still requires the vector types to match. The LLVM IR shuffles can have a different size, but they are forced to match when building the SelectionDAG.

Revision 190916 Commit message: "Lift alignment restrictions for load/store folding on VINSERTF128/VEXTRACTF128. Fixes PR17268." Actual contents of the commit includes Index: tools/opt/opt.cpp =================================================================== --- tools/opt/opt.cpp (revision 190915) +++ tools/opt/opt.cpp (revision 190916) @@ -462,6 +462,7 @@...

...33/bin/llc vstore.ll creates: .section __TEXT,__text,regular,pure_instructions .globl _main .align 4, 0x90 _main: ## @main .cfi_startproc ## BB#0: ## %entry vmovups (%rdi), %xmm0 vinsertf128 $1, 16(%rdi), %ymm0, %ymm0 ret .cfi_endproc .subsections_via_symbols -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130709/f0222f43/attachment.html>

...rote: > >> On Wed, Dec 2, 2009 at 2:44 PM, David Greene <dag at cray.com> wrote: > >> > I'm working on some of the AVX insert/extract instructions.  They're > >> > stupid.  They do not operate on ymm registers, meaning we have to > >> > use VINSERTF128/VEXTRACTF128 and then do the real operation. > >> > > >> > Anyway, I'm looking at how INSERTPS and friends work and noticed that > >> > there are special SelectionDAG nodes for them and corresponding > >> > TableGen dag operators (X86insrtps, for...

...(vector_shuffle (SRCTYPE undef), (SRCTYPE SRCREGCLASS:$src1), VEXTRACTF128_shuffle_mask:$src2), x86_subreg_128bit)))], def x86_subreg_128bit : PatLeaf<(i32 1)>; Curiously, I have analogous patterns for VINSERTF128 that use insert_subreg but it doesn't generate any duplicate case values. Anyone seen something like this before? Any ideas on how to fix it? -Dave

...<8 x i32> %a, %b ret <8 x i32> %add } With march=X86-64 and mcpu=corei7-avx, llc with the default calling convention generates the following code vextractf128 $1, %ymm1, %xmm2 vextractf128 $1, %ymm0, %xmm3 vpaddd %xmm2, %xmm3, %xmm2 vpaddd %xmm1, %xmm0, %xmm0 vinsertf128 $1, %xmm2, %ymm0, %ymm0 ret With this new calling convention, llc would generate slightly different code inside the callee vpaddd %xmm2, %xmm0, %xmm0 vpaddd %xmm3, %xmm1, %xmm1 ret I am wonder how we can specify this rule. I tried to specify this in X86CallingConv.td which...

...{ + extern const unsigned char vmovdqu_from_mem[]; + +#if 0 /* Don''t use AVX2 instructions for now */ + asm volatile ( "vpcmpgtb %%ymm4, %%ymm4, %%ymm4\n" +#else + asm volatile ( "vpcmpgtb %%xmm4, %%xmm4, %%xmm4\n\t" + "vinsertf128 $1, %%xmm4, %%ymm4, %%ymm4\n" +#endif + ".pushsection .test, \"a\", @progbits\n" + "vmovdqu_from_mem: vmovdqu (%0), %%ymm4\n" + ".popsection" :: "d" (NULL) ); + + memcpy(i...

[NOTE: Removed Phab and reviewers] > ================ > Comment at: test/CodeGen/X86/2012-01-12-extract-sv.ll:12 > +; CHECK-NEXT: vblendps {{.*#+}} xmm1 = xmm1[0],xmm2[1,2,3] > +; CHECK-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[0,0,0,0] > ; CHECK-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0 > ---------------- > greened wrote: >> Can we make this test less brittle by using FileCheck variables? >> This goes for pretty much every test in this patch. > I'm sorry but no - its been repeatedly proven that using > update_llc_test_checks.py o...

...fi_def_cfa_offset 8 .Ltmp6: .cfi_offset %ebp, -8 movl %esp, %ebp .Ltmp7: .cfi_def_cfa_register %ebp movl 12(%ebp), %eax .loc 1 9 0 prologue_end # shufxbug.cl:9:0 .Ltmp8: vpermilps $65, 304(%eax), %xmm0 # xmm0 = mem[1,0,0,1] vxorps %xmm1, %xmm1, %xmm1 vinsertf128 $1, %xmm1, %ymm0, %ymm0 movl 16(%ebp), %eax .loc 1 10 0 # shufxbug.cl:10:0 vmovups %ymm0, 608(%eax) .loc 1 11 0 # shufxbug.cl:11:0 popl %ebp vzeroupper ret It seems to me that generated code is not correct in both case can s...

...12-04-26-sdglue.ll Tue Oct 15 18:33:07 2013 >> @@ -5,8 +5,8 @@ >> ; It's hard to test for the ISEL condition because CodeGen optimizes >> ; away the bugpointed code. Just ensure the basics are still there. >> ;CHECK-LABEL: func: >> -;CHECK: vxorps >> -;CHECK: vinsertf128 >> +;CHECK: vpxor >> +;CHECK: vinserti128 >> ;CHECK: vpshufd >> ;CHECK: vpshufd >> ;CHECK: vmulps >> >> Modified: llvm/trunk/test/CodeGen/X86/3addr-16bit.ll >> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/X86/3addr-16bit.ll?rev=19...