LLVM calling convention for AVX2 and AVX512 registers

[Ben Gamari]

Edward Kmett <ekmett at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/a4d3459e/attachment-0001.sig>