Edward Kmett
Hrmm. In C/C++ I can tell individual functions to turn on additional ISA feature sets with compiler-specific __attribute__((target("avx2"))) tricks. This avoids complains from the compiler when I call builtins that aren't available at my current compilation feature level. Perhaps pragmas for the codegen along those lines is what we'd ultimately need? Alternately, if we simply distinguish between what the ghc codegen produces with one set of options and what we're allowed to ask for explicitly with another then user-land tricks like I employ would remain sound.
I'm actually not sure that simply distinguishing between the user- and codegen-allowed ISA extensions is quite sufficient. Afterall, AFAIK LLVM doesn't make such a distinction itself: AFAIK if you write a vector primitive and compile for a target that doesn't have an appropriate instruction the code-generator will lower it with software emulation. However, adding a pragma to allow per-function target annotations seems quite reasonable and easily doable. Moreover, contrary to my previous assertion, it shouldn't require any splitting of compilation units. I ran a quick experiment, compiling this program, __attribute__((target("sse2"))) int hello() { return 1; } With clang. It produced something like, define i32 @hello() #0 { ret i32 1 } attributes #0 = { "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" ... } So it seems LLVM is perfectly capable of expressing this; in hindsight I'm not sure why I ever doubted this. There are a number of details that would need to be worked out regarding how such a pragma should behave. Does the general direction sound reasonable? I've opened #13427 [1] to track this idea. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/13427