simd branch ready for review/merge

Carter Schonwald carter.schonwald at
Tue Sep 24 20:14:04 UTC 2013

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 <marlowsd at> 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 at
>>> ______________________________**_________________
>>> ghc-devs mailing list
>>> ghc-devs at
>>  ______________________________**_________________
> ghc-devs mailing list
> ghc-devs at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list