if you need help setting up a patched llvm to benchmark -fllvm-pass-vectors-in-regs, please feel welcome to ask! On Mon, Sep 16, 2013 at 3:43 PM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

Awesome work Geoff! I look forward to looking at this / playing with it soon!

:)

On Mon, Sep 16, 2013 at 3:16 PM, Geoffrey Mainland wrote:

...

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points:

1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported.

2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM

...

3.4-compiled object files, but I don't see that as much of a problem.

3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.pp.

4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like:

ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx.

This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know.

Thanks, Geoff _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Hey Simon (and everyone else), regarding matter #1: good idea! the static literal idea i've been chewing on, if generalized to also make sense in a DataKinds setting, would give the machinery for writing something like "vecOf :: Static * -> Static Nat -> #" or something like that. On Fri, Sep 20, 2013 at 7:22 AM, Simon Peyton-Jones wrote:

Geoff

I'm too far from this stuff to give it a meaningful review, at least not without sitting beside you. So I suggest you just merge it! Simon Marlow may want to look.

The wiki page http://ghc.haskell.org/trac/ghc/wiki/SIMD/Design describes the design, and I think it's up to date with your patches (correct?). Thanks for doing that!

From our previous discussion, the bit I hate is this:

1 there are so many distinct data types (Int16x4, Int32x2, etc)

2 primops.txt.pp therefore has to grow a macro-like mechanism to ameliorate the burden of writing out all the zillions of types and primops

Concerning (2), the obvious rejoinder is: well, primops.txt.pp is really a program written in a domain specific language -- and that language is getting more elaborate. Solution: stop building a new language, and instead make primops.txt.pp into an embedded DSL in Haskell; just a Haskell program that we run to generate the various outputs. Then all the mechanisms you had to add will be trivial.

Concerning (1) what we want is a way to make types Int<16,4> where the parameters 16 and 4 are forced to be static literals, and where you absolutely do not get polymorphism like f :: Int<a><b> -> blah. There is some Trac discussion about this.

It can't be that hard. I'm copying some FC friends!

Simon

| -----Original Message----- | From: Geoffrey Mainland [mailto:mainland@apeiron.net] | Sent: 16 September 2013 20:17 | To: Simon Peyton-Jones; Simon Marlow; Austin Seipp; ghc-devs@haskell.org | Subject: simd branch ready for review/merge | | The SIMD branch, available as wip/simd, is ready for review/merge. It | could use some review---Simon and Simon, I'd be especially grateful if | you both had a quick look. Some major points: | | 1) I have added support for AVX 512, although this is necessarily | untested. AVX and AVX2 are also both supported. | | 2) After the recent churn regarding patching LLVM's GHC calling | convention, by default only 128-bit wide SIMD vectors are passed in | registers, and then only on X86_64. There is a "hidden" flag, | -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that | assumes all vectors are passed in registers by LLVM. This can be used | with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, | we can consider turning it on by default for LLVM 3.4+. This would mean | that we couldn't mix LLVM <3.3-compiled object files with LLVM | >3.4-compiled object files, but I don't see that as much of a problem. | | 3) utils/genprimcode has been hacked up to allow us to write vector | operations once and have them instantiated at multiple vector types. I'm | not thrilled with this solution, but after discussing with Simon PJ, | what I've implemented seems to be the minimal reasonable solution to the | problem of exploding primop boilerplate. The changes are documented in | compiler/prelude/primops.txt.pp. | | 4) Error handling is sub-optimal. My patch checks to make sure that | vector primops can be compiled efficiently based on the current set of | dynamic flags. For example, if -mavx is not specified and the user tries | to use a primop that adds together two 256-bit wide vectors of | double-precision elements, the user will see an error message like: | | ghc-stage2: sorry! (unimplemented feature or known bug) | (GHC version 7.7.20130916 for x86_64-unknown-linux): | 256-bit wide floating point SIMD vector instructions require at | least -mavx. | | This is because the only good place to check for this kind of error is | during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we | don't have much of an error handling infrastructure there in contrast to | when we're working in the typechecking/renaming monad. If there is a | better way/place to do this, please let me know. | | Thanks, | Geoff _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

The NCG checks for this, but maybe it would be better to add a check in cmm/CmmCallConv.hs? What do you think? Geoff On 09/23/2013 06:31 AM, Simon Marlow wrote:

Hey Geoff,

Sorry for not getting around to reviewing this. I just skimmed the patches and didn't spot anything obviously bogus.

Regarding the sorry errors, are primops the only place that we need to check? Is it possible that the user might try to call a function that takes a SIMD argument and make the NCG fall over that way?

Cheers, Simon

On 16/09/2013 15:16, Geoffrey Mainland wrote:

...

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points:

1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported.

...

3.4-compiled object files, but I don't see that as much of a problem.

2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM 3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.pp.

4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like:

ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx.

This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know.

Thanks, Geoff _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

In terms of normal haskell user experience, would it perhaps be a good ideas to have information like "this inlinable function transitively calls an inlinable function that uses a SIMD primop" in the *.hi files? that way we can, before code gen time, give a warning that compilation of client module might fail without -fllvm? (whether it fails or not depends on how much inlining actually happens ) On Tue, Sep 24, 2013 at 7:25 AM, Simon Marlow wrote:

Yes - it's really just an aesthetic issue, but I think it would be nice if we know that there's only one pass where these errors show up, so we don't have to worry about emitting a helpful "sorry" rather than a panic in other places too.

Cheers, Simon

On 23/09/2013 21:52, Geoffrey Mainland wrote:

...

The NCG checks for this, but maybe it would be better to add a check in cmm/CmmCallConv.hs? What do you think?

Geoff

On 09/23/2013 06:31 AM, Simon Marlow wrote:

...

Hey Geoff,

Sorry for not getting around to reviewing this. I just skimmed the patches and didn't spot anything obviously bogus.

Regarding the sorry errors, are primops the only place that we need to check? Is it possible that the user might try to call a function that takes a SIMD argument and make the NCG fall over that way?

Cheers, Simon

On 16/09/2013 15:16, Geoffrey Mainland wrote:

...

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points:

1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported.

2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM

...

3.4-compiled object files, but I don't see that as much of a problem.

3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.**pp.

4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like:

ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx.

This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.**hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know.

Thanks, Geoff ______________________________**_________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs

______________________________**_________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs

______________________________**_________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/**mailman/listinfo/ghc-devshttp://www.haskell.org/mailman/listinfo/ghc-devs