similar to: [LLVMdev] More AVX Advice Needed

On Wednesday 02 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,

On Wed, Dec 2, 2009 at 3:08 PM, David Greene <dag at cray.com> wrote: > On Wednesday 02 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

On Wednesday 02 December 2009 17:24, Eli Friedman wrote: > On Wed, Dec 2, 2009 at 3:08 PM, David Greene <dag at cray.com> wrote: > > On Wednesday 02 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 >

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

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,

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,

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

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

I am implementing a new calling convention for X86 which requires to pass a 256 bit integer vector with two XMM 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

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

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

- we used the C4/C5 (first prefix) byte instead of the apparent ModR/M one as the second prefix byte - early decoding normalized vex.reg, thus corrupting it for the main consumer (copy_REX_VEX()), resulting in #UD on the two-operand instructions we emulate Also add respective test cases to the testing utility plus - fix get_fpu() (the fall-through order was inverted) - add cpu_has_avx2,

I'll explain what we see in the code. 1. The caller saves XMM registers across the call if needed (according to DEFS definition). YMMs are not in the set, so caller does not take care. 2. The callee preserves XMMs but works with YMMs and clobbering them. 3. So after the call, the upper part of YMM is gone. - Elena -----Original Message----- From: Bruno Cardoso Lopes [mailto:bruno.cardoso at

On Tuesday 24 November 2009 14:12, Anton Korobeynikov wrote: > 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,

On Nov 24, 2009, at 12:19 PM, David Greene wrote: > On Tuesday 24 November 2009 14:12, Anton Korobeynikov wrote: >> 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. >>

On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > I'll explain what we see in the code. > 1. The caller saves XMM registers across the call if needed (according to DEFS definition). > YMMs are not in the set, so caller does not take care. This is not how the register allocator works. It saves the registers holding values, it doesn't care which alias is clobbered. Are you

Hi, > What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. > This is also the default behavior of the Intel Compiler. x86_64 Non-windows targets use the rules defined in the x86_64 abi! > In X86InstrControl.td the YMMs are not in "defs" set of call. The XMMs are subregisters of YMMs, and they are in the

I've been working on adding AVX to LLVM and have run across a number of questions. Here's the first one. In some ways AVX is "just another" SSE level. Having AVX implies you have SSE1-SSE4.2. However AVX is very different from SSE and there are a number of sub-features which may or may not be available on various implementations. So right now I've done this: def

Hi, What is the calling conventions for YMM. According to documents I saw till now, the YMMs are scratch and not saved in callee. This is also the default behavior of the Intel Compiler. In X86InstrControl.td the YMMs are not in "defs" set of call. - Elena --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments

On Jan 9, 2012, at 10:00 AM, Jakob Stoklund Olesen wrote: > > On Jan 8, 2012, at 11:18 PM, Demikhovsky, Elena wrote: > >> I'll explain what we see in the code. >> 1. The caller saves XMM registers across the call if needed (according to DEFS definition). >> YMMs are not in the set, so caller does not take care. > > This is not how the register allocator