similar to: [LLVMdev] AVX Testcases

On Tuesday 05 January 2010 13:20, Dan Gohman wrote: > On Jan 5, 2010, at 9:54 AM, David Greene wrote: > > I should be sending up some AVX code this week. When I do this > > I'd like to generate some testcases to make sure we actually > > generate AVX code. Ideally we'd have a testcase for each AVX > > pattern but that's probably overkill. Still, we'd

On Jan 5, 2010, at 9:54 AM, David Greene wrote: > I should be sending up some AVX code this week. When I do this > I'd like to generate some testcases to make sure we actually > generate AVX code. Ideally we'd have a testcase for each AVX > pattern but that's probably overkill. Still, we'd like a lot > of tests, I think. > > Should these tests go into

Hi, I think that def FeatureVectorUAMem : SubtargetFeature<"vector-unaligned-mem", "HasVectorUAMem", "true", "Allow unaligned memory operands on vector/SIMD instructions">; should be switched-ON on AVX and AVX-512 instructions because: According to the AVX spec: "Most arithmetic and

AFAIK, there is no additional penalty for AMD processors. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Chandler Carruth Sent: Monday, December 15, 2014 3:57 AM To: Demikhovsky, Elena Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Memory alignment model on AVX, AVX2 and AVX-512 targets FWIW, this makes sense to me. I'd be interested to hear from

I'd like to start moving some of our AVX work into trunk. We've got quite a bit of it implemented already. I wanted to make sure we got something that would work and remain relatively stable. Here's how I'd like to do this. First, I have some more TableGen fixes and enhancements that are prereqs for AVX templates. I'd like to get those in first. Then there are a number of

Hello, I want to disable LLVM to use any SIMD registers like sse and avx. I tried -mno-sse and -mno-avx on my Core i7 machine. It seems that the generated assembly still uses xmm registers. Is there any way for LLVM to only use scalar registers? Thanks, Zhi -------------- next part -------------- An HTML attachment was scrubbed... URL:

Here's the big RFC. A I've gone through and designed patterns for AVX, I quickly realized that the existing SSE pattern specification, while functional, is less than ideal in terms of maintenance. In particular, a number of nearly-identical patterns are specified all over for nearly-identical instructions. For example: let Constraints = "$src1 = $dst" in { multiclass

On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > A I've gone through and designed patterns for AVX, I quickly > realized that the > existing SSE pattern specification, while functional, is less than > ideal in > terms of maintenance. In particular, a number of nearly-identical > patterns > are specified all over for

On Tuesday 07 April 2009 01:18, someguy wrote: > Can you give an example of where you would use such a feature? > It seems entirely too abstract (at least to me) at the moment. Basically I wanted to pass the various prefix encoding classes (XS, XD, etc.) down into generic SIMD multiclasses so that we could write rr / rm patterns once and reuse them with different prefix encoding base

Hi David, On 30-Apr-09, at 6:59 PM, David Greene wrote: > This is not scalable. > > So what I've done is a little experiment to see if I can unify all > SSE and AVX > SIMD instructions under one framework. I'll leave MMX and 3dNow > alone since > they're oddballs and hardly anyone uses them. I don't want to unnecessarily expand your scope, but while

Thanks, Mats. Actually, it is able to generate the assembly now if I use the follow command: clang++ -O3 -S -mllvm --x86-asm-syntax=intel -mno-sse -o test_nosee.s test.cpp However, when I use g++ -O3 -o test_nosse test_nosse.s -lm to generate the executable, if gives me the following errors: Error: too many memory references for `sub' Error: too many memory references for `mov' Error:

On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > > Of course we would not transition away from X86InstrSSE.td until > X86InstrSIMD.td is proven to cover all current uses of SSE correctly. > > The pros of the scheme: > > * Unify all "important" x86 SIMD instructions into one framework and > provide > consistency While

Ralf Karrenberg <Chareos at gmx.de> writes: > This sounds great! > > For my case, I only require some basic support, so I am optimistic > that your next few patches will provide everything I need. If my evil plan works out, within the next 10 or so patches we should be in a place where pushing everything up goes pretty quickly. It's about 8 TableGen patches and then a

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: > 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

Hi David, >> 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? > > Yes, we are! I am doing a lot of tuning work at the moment. We have > been rather swamped with work for new products and I am now just getting > out

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

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.

On Friday 01 May 2009 13:46, Chris Lattner wrote: > Right, a lot of these problems can be solved by some nice refactoring > stuff. I'm also hoping that some of the complexity in defining > shuffle matching code can be helped by making the definition of the > shuffle patterns more declarative within the td file. It would be > really nice to say that "this shuffle does a

On 2 October 2013 10:12, Steven Newbury <steve at snewbury.org.uk> wrote: > How does this make any sense? > I have to agree with you that this doesn't make much sense, but there is a case where you would want something like that: when the original source uses NEON intrinsics, and there is no alternative in AltiVec, AVX or even plain C. We encourage people to use NEON intrinsics,