similar to: [LLVMdev] Moving AVX Upstream

On Nov 2, 2009, at 11:48 AM, David Greene wrote: > Hey everyone, > > I'm at the point with our local AVX tree that I'm ready to move some > stuff upstream. We've got most of the basic stuff implemented. The > more esoteric stuff still has to be done. > > Because the more esoteric stuff might require some extensive changes > to > the existing AVX

On Monday 02 November 2009 13:55, Tanya Lattner wrote: > You should do incremental development on trunk. If you create a > branch, no one is going to look at those changes. Ok. but I want to be very clear what that means. It means for each AVX instruction I rip out ALL of the existing SSE support for it. So when ADD gets implemented, ADD goes away from X86InstSSE.td. As things progress,

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

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

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 Nov 2, 2009, at 12:51 PM, David Greene wrote: > On Monday 02 November 2009 13:55, Tanya Lattner wrote: >> You should do incremental development on trunk. If you create a >> branch, no one is going to look at those changes. > > Ok. but I want to be very clear what that means. It means for each > AVX > instruction I rip out ALL of the existing SSE support for it.

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

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

I installed Samba2.0.7 on my FreeBSD 4.1 box and joined an NT domain. It worked perfect until I changed the hostname today. I found that I couldn't chage the machine password if hostname length is 15. The precedure I do is 1. stop samba 2. change hostname to "abcde1234567890" 3. run smbpasswd -j DOM -r DomControl, then I get the following error message. cli_net_auth2: Error

Henning, I believe the code that is supposed to do this is in: lib/Target/X86/X86Subtarget.cpp in X86Subtarget::AutoDetectSubtargetFeatures() Is there a bug in that function? -Hal On Thu, 24 May 2012 23:56:48 +0200 (CEST) Henning Thielemann <llvm at henning-thielemann.de> wrote: > > On Thu, 24 May 2012, Pan, Wei wrote: > > > Very likely AVX is not enabled in your llc.

On Thu, 24 May 2012, Pan, Wei wrote: > Very likely AVX is not enabled in your llc. This feature was enabled > just recently (late of April). I forgot to mention that I am using recent LLVM-3.1 and in principle my llc knows about avx as I have shown in the second example. But avx does not seem to be used by default. On Thu, 24 May 2012, Henning Thielemann wrote: > $ llc -o - -mattr

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

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,

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 wonder why AVX is not used automatically if available at the host machine. In contrast to that, SSE41 instructions (like pmulld) are automatically used if the host machine supports SSE41. E.g. $ cat avx.ll define void @_fun1(<8 x float>*, <8 x float>*) { _L1: %x = load <8 x float>* %0 %y = load <8 x float>* %1 %z = fadd <8 x float> %x, %y store

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

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 Thu, 24 May 2012, Hal Finkel wrote: > Henning, > > I believe the code that is supposed to do this is in: > lib/Target/X86/X86Subtarget.cpp in > X86Subtarget::AutoDetectSubtargetFeatures() > Is there a bug in that function? I read there: // FIXME: AVX codegen support is not ready. //if ((ECX >> 28) & 1) { X86SSELevel = AVX; ToggleFeature(X86::FeatureAVX); }

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 CodeGen/X86 or should I create a new space, like CodeGen/X86/SIMD? I tend to favor the