Edward Kmett <ekm...@gmail.com> writes: > 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
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs