On Mon, Feb 4, 2013 at 3:19 PM, Geoffrey Mainland
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