simd branch ready for review/merge

[Simon Marlow]

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