LLVM calling convention for AVX2 and AVX512 registers

[Siddhanathan Shanmugam]

> I would be happy to advise if you would like to pick this up.

Thanks Ben!

> This would mean that Haskell libraries compiled with different flags
> would not be ABI compatible.

Wait, can we not maintain ABI compatibility if we limit the target
features using a compiler flag? Sometimes (for performance reasons)
it's reasonable to request the compiler to only generate SSE
instructions, even if AVX2 is available on the target. On GCC we can
use the flag -msse to do just that.

On Tue, Mar 14, 2017 at 5:49 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> This thread is getting into a broader discussion about target specific
> intrincsics as user prims vs compiler generated.
>
> @ben - ed is talking about stuff like a function call that's using a
> specific avx2 intrinsic, not the parameterized vector abstraction. LLvm
> shouldn't be lowering those. ... or clang has issues :/
>
> On Tue, Mar 14, 2017 at 4:33 PM Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>>
>> On 03/14/2017 04:02 PM, Ben Gamari wrote:
>> > 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.
>>
>> This would mean that Haskell libraries compiled with different flags
>> would not be ABI compatible.
>>
>> Our original paper exposed a Multi type class that was meant to be the
>> programmer interface to the primops. A Multi a would be the widest
>> vector type supported on the current architecture, so code that used a
>> Multi Double would always be guaranteed to work at the widest vector
>> type available for Double's.
>>
>> The Multi approach explicitly eschewed lowering, but I would argue that
>> if performance is the goal, then automatic lowering is not what you
>> want. I would rather have the system pick the correct vector width for
>> me based on the current architecture.
>>
>> This does nothing to solved the problem of ABI compatibility, which is
>> one reason I didn't push to get this upstreamed.
>>
>> Is the Multi approach desirable? I think it would be nice to be able to
>> at least provide such a solution even if it isn't some sort of default.
>> Do we really want lowering of wider vector types?
>>
>> Geoff
>>
>> > 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
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>