Re: LLVM calling convention for AVX2 and AVX512 registers

On Wed, Mar 15, 2017 at 5:44 PM, Ben Gamari wrote: > Carter Schonwald writes: > > > No matter *how* ghc ultimately bundles simd for high level > > programming, it *will* have to bottom out into these target specific > > operations at code gen

Re: LLVM calling convention for AVX2 and AVX512 registers

Carter Schonwald writes: > No matter *how* ghc ultimately bundles simd for high level > programming, it *will* have to bottom out into these target specific > operations at code gen time, and LLVM is *not* an abstraction for it. > I am very interested to hear what you

Re: LLVM calling convention for AVX2 and AVX512 registers

It's a bit unclear from this comment whether this statement is a critique of a particular implementation strategy for adding SIMD support to the NCG or a more general reflection on SIMD interfaces. From your later messages I infer the latter in my response; feel free to disregard if I

Re: LLVM calling convention for AVX2 and AVX512 registers

Carter Schonwald writes: > solution: lets call these registers what they are, instead of pretending > they're portable. we are not going to find the right abstraction in the > first go. lets not do that. first get it working sanely, then figure out > proper

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it > deliberately crashes out during code generation, no? I very well be missing something, but I don't believe this is true. This program compiles just fine with merely -fllvm -msse,

Re: LLVM calling convention for AVX2 and AVX512 registers

to reiterate: any automated lowering / shimming scheme will hurt any serious user of simd who isn't treating it as some black box abstraction. And those are the very users who are equipped to write / design libraries / ghc improvements that let still *other* users pretend to have a mostly decent

Re: LLVM calling convention for AVX2 and AVX512 registers

agreed. and the generic vector size stuff in llvm is both pretty naive, AND not the sane/tractable way to add SIMD support to the NCG, i'm totally ok with my vector sizes that are available depending on the target CPU or whatever. Operating systems have very sane errors for that sort of mishap,

Re: LLVM calling convention for AVX2 and AVX512 registers

Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it deliberately crashes out during code generation, no? So this is very deliberately *not* a problem with the current setup as I understand it. It only becomes one if we reverse the decision and decide to add terribly

Re: LLVM calling convention for AVX2 and AVX512 registers

Ok so 1) xmm when not using fancy features 2) lets not have types that vary with the abi then! i genuinely think that this is one of those domains where "no abstraction" is a better starting point than "wrong abstraction" I believe both edward kmett and I genuinely want to be users of simd on

Re: LLVM calling convention for AVX2 and AVX512 registers

solution: lets call these registers what they are, instead of pretending they're portable. we are not going to find the right abstraction in the first go. lets not do that. first get it working sanely, then figure out proper abstractions On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari

Re: LLVM calling convention for AVX2 and AVX512 registers

Siddhanathan Shanmugam writes: >> I would be happy to advise if you would like to pick this up. > > Thanks Ben! > >> This would mean that Haskell libraries compiled with different flags >> would not be ABI compatible. > > Wait, can we not maintain ABI compatibility if

Re: LLVM calling convention for AVX2 and AVX512 registers

> I would be happy to advise if you would like to pick this up. Thanks Ben! > This would mean that Haskell libraries compiled with different flags > would not be ABI compatible. Wait, can we not maintain ABI compatibility if we limit the target features using a compiler flag? Sometimes (for

Re: LLVM calling convention for AVX2 and AVX512 registers

This thread is getting into a broader discussion about target specific intrincsics as user prims vs compiler generated. @ben - ed is talking about stuff like a function call that's using a specific avx2 intrinsic, not the parameterized vector abstraction. LLvm shouldn't be lowering those. ... or

Re: LLVM calling convention for AVX2 and AVX512 registers

On 03/14/2017 04:02 PM, Ben Gamari wrote: > Edward Kmett writes: > >> Hrmm. In C/C++ I can tell individual functions to turn on additional ISA >> feature sets with compiler-specific __attribute__((target("avx2"))) tricks. >> This avoids complains from the compiler when I call

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > Hrmm. In C/C++ I can tell individual functions to turn on additional ISA > feature sets with compiler-specific __attribute__((target("avx2"))) tricks. > This avoids complains from the compiler when I call builtins that aren't > available at my current

Re: LLVM calling convention for AVX2 and AVX512 registers

Hrmm. In C/C++ I can tell individual functions to turn on additional ISA feature sets with compiler-specific __attribute__((target("avx2"))) tricks. This avoids complains from the compiler when I call builtins that aren't available at my current compilation feature level. Perhaps pragmas for the

Re: LLVM calling convention for AVX2 and AVX512 registers

Edward Kmett writes: > That, rather tangentially, reminds me: If we do start to teach the code > generator about how to produce these sorts of things from simpler parts, > e.g. via enabling something like LLVM's vectorization pass, or some > internal future ghc compiler pass

Re: LLVM calling convention for AVX2 and AVX512 registers

That, rather tangentially, reminds me: If we do start to teach the code generator about how to produce these sorts of things from simpler parts, e.g. via enabling something like LLVM's vectorization pass, or some internal future ghc compiler pass that checks for, say, Superword-Level Parallelism

Re: LLVM calling convention for AVX2 and AVX512 registers

> It would be even better if we could *also* teach the native back end about SSE instructions. Is there anyone who might be willing to work on that? Yes. Though, it would be better if someone with more experience than me decides to pick this up instead. On Thu, Mar 9, 2017 at 7:00 PM, Edward

Re: LLVM calling convention for AVX2 and AVX512 registers

If we only turn on ymm and zmm for passing explicit 256bit and 512bit vector types then changing the ABI would have basically zero effect on any code anybody is actually using today. Everything would remain abi compatible unless it involves the new types that nobody is using. This also has the

Re: LLVM calling convention for AVX2 and AVX512 registers

zooming out: what *should* the new ABI be? Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers (depending on how they're being used) caller save, (what about all 32 zmm registers? would they be float only, or also for ints/words? simd has lots of nice int support!) a) if this

Re: LLVM calling convention for AVX2 and AVX512 registers

the patch is still on TRAC, https://ghc.haskell.org/trac/ghc/ticket/8033 we need to do changes to both the 32bit and 64bit ABIs, and I think thats where I got stalled from lack of feedback that aside: heres the original email thread on the llvm commits thread

Re: LLVM calling convention for AVX2 and AVX512 registers

We would need to get a patch to LLVM accepted to change the GHC calling convention. Now that we commit to a particular version of LLVM, this might be less of an issue than it once was since we wouldn't have to support versions of LLVM that didn't support the new calling convention. So...how do

LLVM calling convention for AVX2 and AVX512 registers

Back around 2013, Geoff raised a discussion about fixing up the GHC ABI so that the LLVM calling convention could pass 256 bit vector types in YMM (and, i suppose now 512 bit vector types in ZMM). As I recall, this was blocked by some short term concerns about which LLVM release was imminent or