search for: vextractf128

The AVX saga continues. I am attempting to write a pattern for VEXTRACTF128 but am having some problems. My attempt looks something like this: defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, MRMDestMem, "extractf128", undef, X86f32, X86i32i8, // rr [(set VR128:$dst,...

I think that it should not belong to any domain. And I see a problem with this table. 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 a...

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::VEXTRACTI128mr }, { X86::VEXTRACTF128rr, X86::VEXTRACTF128rr, X86::VEXTRACTI128rr }, { X86::VINSERTF128rm, X86::VINSERTF128rm, X86::VINSERTI128rm }, { X86::VINSERTF128rr, X86::VINSERTF128rr, X86::VINSERTI128rr }, { X86::VPERM2F128rm, X86::VPERM2F128rm, X...

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 confidential material for the sole use of the intended recipient(s). Any review or distribution...

On Wed, Dec 2, 2009 at 3:46 PM, David Greene <dag at cray.com> wrote: > The AVX saga continues. > > I am attempting to write a pattern for VEXTRACTF128 but am having some > problems.  My attempt looks something like this: > > defm EXTRACTF128 : avx_fp_extract_vector_osta_node_mri_256<0x19, MRMDestReg, >                      MRMDestMem, "extractf128", undef, X86f32, X86i32i8, >                   // rr >              ...

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 to intrinsic...

...09 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's the reas...

...fter the vectorizer. This is 8-element SVML sin() called with 8-element argument. On the surface, this looks very good. Later on, standard vector type legalization kicks-in but only the argument and return data are legalized. vmovaps %ymm0, %ymm1 vcvtdq2pd %xmm1, %ymm0 vextractf128 $1, %ymm1, %xmm1 vcvtdq2pd %xmm1, %ymm1 callq __svml_sin8 vmovups %ymm1, 32(%r15,%r12,8) vmovups %ymm0, (%r15,%r12,8) Unfortunately, __svml_sin8() doesn't use this form of input/output. It takes zmm0 and returns zmm0. i.e., not legal to use for AVX. W...

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 special dag opera...

...iedman 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.

I'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))...

...registers rather than one YMM register. For example define <8 x i32> @add(<8 x i32> %a, <8 x i32> %b) { %add = add <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, %xm...

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 @@ Di...

...gt;> 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). &gt...

...ack. The callee, however, begins with __Z14convert_char16Dv16_s: ## @_Z14convert_char16Dv16_s .cfi_startproc ## BB#0: ## %entry pushq %rbp Ltmp2: .cfi_def_cfa_offset 16 Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp Ltmp4: .cfi_def_cfa_register %rbp vextractf128 $1, %ymm0, %xmm1 which expects the argument in %ymm0. However, the vzeroupper in the caller just destroyed part of %ymm0... My question is: What decides this calling convention? I know that standard x86-64 should pass arguments in %xmm0, not %ymm0. Are there e.g. command line options, CPU attrib...

...fter the vectorizer. This is 8-element SVML sin() called with 8-element argument. On the surface, this looks very good. Later on, standard vector type legalization kicks-in but only the argument and return data are legalized. vmovaps %ymm0, %ymm1 vcvtdq2pd %xmm1, %ymm0 vextractf128 $1, %ymm1, %xmm1 vcvtdq2pd %xmm1, %ymm1 callq __svml_sin8 vmovups %ymm1, 32(%r15,%r12,8) vmovups %ymm0, (%r15,%r12,8) Unfortunately, __svml_sin8() doesn't use this form of input/output. It takes zmm0 and returns zmm0. i.e., not legal to use for AVX. W...

...gt;> surface, this looks very good. >> >> Later on, standard vector type legalization kicks-in but only the >> argument and return data are legalized. >> >> vmovaps %ymm0, %ymm1 >> >> vcvtdq2pd %xmm1, %ymm0 >> >> vextractf128 $1, %ymm1, %xmm1 >> >> vcvtdq2pd %xmm1, %ymm1 >> >> callq __svml_sin8 >> >> vmovups %ymm1, 32(%r15,%r12,8) >> >> vmovups %ymm0, (%r15,%r12,8) >> >> Unfortunately, __svml_sin8() doesn’t use this fo...

...called with 8-element argument. On the > surface, this looks very good. > > Later on, standard vector type legalization kicks-in but only the argument > and return data are legalized. > > vmovaps %ymm0, %ymm1 > > vcvtdq2pd %xmm1, %ymm0 > > vextractf128 $1, %ymm1, %xmm1 > > vcvtdq2pd %xmm1, %ymm1 > > callq __svml_sin8 > > vmovups %ymm1, 32(%r15,%r12,8) > > vmovups %ymm0, (%r15,%r12,8) > > Unfortunately, __svml_sin8() doesn’t use this form of input/output. It > takes zmm0 a...

...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),...