Make native (CPU) runQ parametric on target machine

[michael-swan]

Is your feature request related to a problem? Please describe.
Currently, native CPU code compilation passes -march=native to the compiler which will cause issues if the target-machine != the machine on which we compile our Haskell program. This causes illegal instructions to be inserted.

Describe the solution you'd like
I see three possibilities:

1. Make a variant of runQ that is parametric on target information
2. Build multiple executable binaries for multiple performance-affecting feature flag variants (i.e. build plain ARM64 binary and also ARM64+SVE binary and also ARM64+SVE+SME, etc.) and gate choice of binary at run-time with target information
3. Simply compile runQ code with exactly the same level of target-specificity as GHC was provided when the program was itself built. If GHC was compiled with -march=native then it should be safe to use -march=native on our Accelerate code too.

[ivogabe]

Good point, we should do something with runQ to make it more portable and/or support cross compilation. I'm not sure yet what the best solution would be though. I think all your suggestions have some value. A quick sketch Tom and I had was to add a new function runQFor :: [Target] -> ... which behaves like runQ, but allows you to specify for which targets you want to compile. Then we can define runQ = runQFor [native] (where native is the 'native target'), and runQPortable = runQ [x86sse, x86avx, ...] (as your option 2).

This would require some engineering, some concrete things we would need to do:

• At runtime decide which variant we should execute,
• Adapt the cache to treat the same program, compiled for different targets, not as the same thing,
• For runQPortable or your option 2, we should decide on how we build a list of targets. Do we want to specialize on each hardware generation (and compile the program 50 times, sounds like a bad idea), or can we use more high level separations like whether it supports sse, sse2, avx, avx2 or avx512 (even in this approach, we are already compiling the program 5 times).

I don't think we have the time to implement this on a short term however, but I do want to keep this on the radar. If you or others have more thoughts or suggestions, feel free to share them.

[michael-swan]

That sounds sane. Worth noting for when deciding default "portable" set of targets that P(avx2 supported | avx supported) is large and P(sse2 not supported) is vanishingly small, especially true of P(sse2 not supported | user wants to use a modern high-performance Haskell library). A similar sort of inference can be done for each ARM NEON extension as well.