simd branch ready for review
mainland at apeiron.net
Fri Feb 1 09:59:13 CET 2013
On 02/01/2013 08:47 AM, Simon Marlow wrote:
> On 01/02/13 08:19, Geoffrey Mainland wrote:
>> On 02/01/2013 08:03 AM, Simon Marlow wrote:
>>> On 31/01/13 20:30, Geoffrey Mainland wrote:
>>>> 2) SSE support is processor and platform dependent. What is the proper
>>>> way for the programmer to know what SSE primitives are available? A CPP
>>>> define? If so, what should it be called?
>>>> Right now one can look at the TARGET_* and __GLASGOW_HASKELL_LLVM__ CPP
>>>> macros and make a decision as to whether or not SSE primitives are
>>>> available, but that's not a great solution. Also, what happens when we
>>>> want to add AVX support? How do we control the inclusion of AVX support
>>>> when building GHC, and how do we let the programmer know that the AVX
>>>> primops/primtypes are available for use?
>>> We #define __SSE__: http://hackage.haskell.org/trac/ghc/ticket/7554
>>> Similar things would need to happen for AVX.
>> If I invoke ghc with -msse on a Win32 box then __SSE__ will be 1, but
>> that doesn't mean I will be able to use SSE primops due to the stack
>> alignment issue on that platform.
> I guess we should not allow -msse with -fllvm on Win32. Or perhaps
> not -msse at all.
Hm, OK, but that would also means external C files could not be compiled
with -msse when using the LLVM back-end on Win32 since we pass the flags
through to the C compiler, right?
>> Also, the decision as to whether or not SSE primops will be available at
>> all needs to be made when GHC is itself built. How should we expose that
> Why does it need to be decided at build time? Isn't it dependent on
> -msse on x86-32, and always available on x86-64?
The primops would need to be compiled in to GHC for -msse to be able
In general, how would we make the set of primops and primtypes a
function of dynflags? It's my understanding that this isn't possible
right now. Or is it?
And what about GHC.PrimopWrappers?
>> As an aside, what's the proper way for me to test the ARM
>> cross-compilation support? I'm afraid my patches may break things there.
> You could follow the instructions for building an RPi cross-compiler here:
> it should be fairly smooth.
More information about the ghc-devs