simd branch ready for review/merge

[Carter Schonwald]

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 gmail.com> 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 haskell.org
>>>> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs>
>>>>
>>>
>>> ______________________________**_________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs>
>>>
>>>
>>  ______________________________**_________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/**mailman/listinfo/ghc-devs<http://www.haskell.org/mailman/listinfo/ghc-devs>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130924/b66f96d7/attachment.htm>