LLVM calling convention for AVX2 and AVX512 registers

[Ben Gamari]

It's a bit unclear from this comment whether this statement is a
critique of a particular implementation strategy for adding SIMD support
to the NCG or a more general reflection on SIMD interfaces. From your
later messages I infer the latter in my response; feel free to disregard
if I misinterpreted.

Carter Schonwald <carter.schonwald at gmail.com> writes:

> agreed. and the generic vector size stuff in llvm is both pretty
> naive, AND not the sane/tractable way to add SIMD support to the NCG,
>
I don't see why this is true. I think it's fair to say that the LLVM
folks have put a lot more thought into SIMD support than any of us here;
consequently I tend to put a fair amount of trust in what they have to
say about the matter. Moreover, it seems to me like they came up with a
pretty sensible abstraction from which they can produce very good code.

Is the abstraction perfect? Of course not; they poke holes where
necessary to expose truly platform specific functionality. However, it
seems they rarely find it necessary to use these holes: In playing
around with Clang I found that almost all of the standard vector
operations lowered to the "naive" abstract operations.

I don't see why we can't provide a similar approach: provide abstract
types and some basic operations (as we already do), supplemented with
tailored primops far target-specific functionality.

My generally, I think we should have a very good reason before we go off
and chart our own course here.

> i'm totally ok with my vector sizes that are available depending on the
> target CPU or whatever. Operating systems have very sane errors for that
> sort of mishap,
>
If the user wants to be more careful about using precisely the vector
support that their target offers then that is their perogative. Unless
I'm missing something there is nothing stopping them under the current
scheme.

Cheers,

- Ben
-------------- 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/20170315/dfe1934d/attachment.sig>