simd branch ready for review

[Johan Tibell]

On Mon, Feb 4, 2013 at 3:19 PM, Geoffrey Mainland <mainland at apeiron.net>wrote:

> What would a sensible fallback be for AVX instructions? What should we
> fall back on when the LLVM backend is not being used?
>

Depends on the instruction. A 256-bit multiply could be replaced by N
multiplies etc. For popcount we have a little bit of C code in ghc-prim
that we use if SSE 4.2 isn't enabled. An alternative is to emit some
different assembly in e.g. the x86-64 backend if AVX isn't enabled.


> Maybe we could desugar AVX instructions to SSE instructions on platforms
> that support SSE but not AVX, but in practice people would then #ifdef
> anyway and just use SSE if AVX weren't available.
>

I don't follow here. If you conditionally emitted different instructions in
the backends depending on which -m flags are passed to GHC, why would
people #ifdef?


> The current idea is to hide the #ifdefs in a library. Clients of the
> library would then get the "best" short-vector implementation available
> for their platform by using this library. Right now this library is a
> modified version of primitive, and I have modified versions of vector
> and DPH that use this version of the primitive library to generate SSE
> code.
>

You would still end up with an GHC.Exts that exports a different API
depending on which flags (e.g. -m<something>) are passed to GHC. Couldn't
you use ghc-prim for your fallbacks and have GHC.Exts.yourPrimOp use either
those fallbacks or the AVX instructions.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130204/c05ea796/attachment.htm>