similar to: [LLVMdev] Status of AVX support

Even if you explicitly specify –stack-alignment=16 the aligned movs are still generated. It is not an issue related to ABI. See my original mail: ./llc -mattr=+avx -stack-alignment=16 < basic.ll | grep movaps | grep ymm | grep rbp vmovaps -176(%rbp), %ymm14 vmovaps -144(%rbp), %ymm11 vmovaps -240(%rbp), %ymm13 - Elena From: Cameron McInally

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

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

Hi, The last time the AVX backend was mentioned on this list seems to be from November 2010, so I would like to ask about the current status. Is anybody (e.g. at Cray?) still actively working on it? I have tried both LLVM 2.9 final and the latest trunk, and it seems like some trivial stuff is already working and produces nice code for code using <8 x float>. Unfortunately, the backend

Hi Ralf On Wednesday, June 1, 2011, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi, > > The last time the AVX backend was mentioned on this list seems to be > from November 2010, so I would like to ask about the current status. Is > anybody (e.g. at Cray?) still actively working on it? I don't think so! > I have tried both LLVM 2.9 final and the latest trunk, and it

Thanks Syoyo and Bruno for your replies. As suggested, I filed a bug under http://llvm.org/bugs/show_bug.cgi?id=10073 . I am not familiar with .td files and the LLVM backend infrastructure yet, but I might give it a try and solve it myself if I find the time. Best, Ralf Am 02.06.2011 23:55, schrieb Bruno Cardoso Lopes: > Hi Ralf > > On Wednesday, June 1, 2011, Ralf

Hi Bruno, > Some comments: > > + // Try to synthesize horizontal adds from adds of shuffles. > + if (((Subtarget->hasSSE3()&& (VT == MVT::v4f32 || VT == MVT::v2f64)) || > + (Subtarget->hasAVX()&& (VT == MVT::v8f32 || VT == MVT::v4f64)))&& > + isHorizontalBinOp(LHS, RHS, true)) > > 1) You probably want to do something like: >

Now that Bruno is putting in some AVX stuff, it's a good motivator to move my x86 SIMD reorg work into trunk (and got management to agree to prioritize it - Thanks Bruno! :) ). Attached is the first patch of many to accomplish this. The overall goal is to have all x86 SIMD instructions share a set of common patterns so that we can have a more maintainable machine description (e.g. SS, SD,

Hi Matt, I am unsure about MCJIT, but I guess the problem is the same. Just like when invoking llc, you need to pass the information to use AVX (llc -mattr=+avx). I guess the corresponding code should look like this: llvm::EngineBuilder engineBuilder(module); engineBuilder.setErrorStr(&eeError); engineBuilder.setEngineKind(llvm::EngineKind::JIT);

Frank, It sounds like the SLP vectorizer thinks that it is more profitable to use 128bit wide operations (because 256bit operations are double pumped on Sandybridge). Did you see a different result on Haswell? Thanks, Nadav > On Jul 1, 2015, at 11:06 AM, Frank Winter <fwinter at jlab.org> wrote: > > I realized that the function parameters had no alignment attributes on them.

Hi Frank, What does --debug-only=vectorize says? You may try to get the datalayout and the triple on the IR header, just to make sure you got everything right. LLVM will honour those, and front-ends should create them correctly. --renato On 1 July 2015 at 19:06, Frank Winter <fwinter at jlab.org> wrote: > I realized that the function parameters had no alignment attributes on them.

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

Hi David, On Fri, Jul 9, 2010 at 3:25 PM, David Greene <dag at cray.com> wrote: > Now that Bruno is putting in some AVX stuff, it's a good motivator to > move my x86 SIMD reorg work into trunk (and got management to agree to > prioritize it - Thanks Bruno! :) ). > > Attached is the first patch of many to accomplish this.  The overall > goal is to have all x86 SIMD

I have a few questions about the new vector shuffle matching code in the x86 .td files. It's a big improvement over the old system and provides the context that code generation for AVX needs. This is great! I'm asking because I'm having some trouble converting some AVX patterns over to the new system. I'm getting this error from tblgen: VyPERM2F128PDirrmi: (set:isVoid

David Greene <dag at cray.com> writes: > I'm asking because I'm having some trouble converting some AVX patterns > over to the new system. I'm getting this error from tblgen: > > VyPERM2F128PDirrmi: (set:isVoid VR256:v4i64:$dst, (vector_shuffle:v4i64 VR256:v4i64:$src1, (ld:v4i64

I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I assume that I'm just not doing something necessary for initialization, but I'm not sure what it would be--I am

Thanks Reid - I'm on Windows. I guess I just assumed I was missing something obvious in how to hook up the JIT and disassembler! Given the nice looking disassembly code I found, I thought people would be doing it all the time :-) b. On Tue, Jul 6, 2010 at 8:41 PM, Reid Kleckner <reid.kleckner at gmail.com> wrote: > If you're on a recent flavor of Linux, you may be able to just

On Fri, Mar 02, 2012 at 11:58:29AM -0500, Cameron McInally wrote: > On Fri, Mar 2, 2012 at 11:32 AM, Evandro Menezes <emenezes at codeaurora.org> > wrote: > ... > > Figure 3.3 on page 16 of www.x86-64.org/documentation/abi.pdf is not > > normative. See foot note 7 in the same page. Figure 3.4 on page 21 > > confirms that the use of a frame-pointer is optional.

> Maybe.  We still have the old operators like unpck and shup, so couldn't > those still trigger?  Shouldn't we remove them if we're using this > TargetNode method? > > Is it very expensive to check masks, in the grand scheme of things? Probably not, in the old scheme the masks could be checked more than once during legalization and also more than once in the tablegen

Hi, today I tried to configure a guest using Virt-Manager and used the "copy host cpu configuration" option which resultet in a "Sandy Bridge" model. What I noticed is that for example the "aes" extension is not available in the guest even though it is available on the host cpu. This is what the host cpu looks like: model name : Intel(R) Xeon(R) CPU E5-2650 v3 @