simd branch ready for review
johan.tibell at gmail.com
Tue Feb 5 00:56:28 CET 2013
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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs