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