simd branch ready for review/merge

[Carter Schonwald]

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 at 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 <mainland at apeiron.net>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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130916/a96da1bf/attachment.htm>