simd branch ready for review/merge

[Simon Marlow]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs