LLVM calling convention for AVX2 and AVX512 registers

Geoffrey Mainland mainland at apeiron.net
Thu Mar 9 20:11:39 UTC 2017


We would need to get a patch to LLVM accepted to change the GHC calling
convention.

Now that we commit to a particular version of LLVM, this might be less
of an issue than it once was since we wouldn't have to support versions
of LLVM that didn't support the new calling convention.

So...how do we get a patch into LLVM? I believe I once had such a patch
ready to go...I will dig around for it, but the change is very small and
easily recreated.

It would be even better if we could *also* teach the native back end
about SSE instructions. Is there anyone who might be willing to work on
that?

Geoff

On 3/9/17 2:30 PM, Edward Kmett wrote:
> Back around 2013, Geoff raised a discussion about fixing up the GHC
> ABI so that the LLVM calling convention could pass 256 bit vector
> types in YMM (and, i suppose now 512 bit vector types in ZMM).
>
> As I recall, this was blocked by some short term concerns about which
> LLVM release was imminent or what have you. Four years on, the exact
> same sort of arguments could be dredged up, but yet in the meantime
> nobody is really using those types for anything.
>
> This still creates a pain point around trying to use these wide types
> today. Spilling rather than passing them in registers adds a LOT of
> overhead to any attempt to use them that virtually erases any benefit
> to having them in the first place.
>
> I started experimenting with writing some custom primops directly in
> llvm so I could do meaningful amounts of work with our SIMD vector
> types by just banging out the code that we can't write in haskell
> directly using llvm assembly, and hoping I could trick LLVM to do link
> time optimization to perhaps inline it, but I'm basically dead in the
> water over the overhead of our current calling convention, before I
> even start, it seems, as if we're spilling them there is no way that
> inlining / LTO could hope to figure out what we're doing out as part
> of the spill to erase that call entirely.
>
> It is rather frustrating that I can't even cheat. =/
>
> What do we need to do to finally fix this?
>
> -Edward



More information about the ghc-devs mailing list