[llvm-bugs] [Bug 28963] AVX512: Update __vectorcall calling conventions

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=28963

Wenzel Jakob <wenzel.jakob at epfl.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #2 from Wenzel Jakob <wenzel.jakob at epfl.ch> ---
Dear David,

I've reopened the ticket since the issue is a bit more tricky in my opinion. I
could also open another ticket with a broader scope and close this one if you
would prefer that.

The problem is basically as follows: In comparison to the other big 2 compilers
with AVX512 support (Intel & GCC), Clang does not provide calling conventions
which allow passing AVX512 SIMD vectors via registers.  This introduces
unnecessary performance penalties in functions that expect vector arguments.

In comparison:

1. GCC does this by default, even without specifying specific calling
conventions. (!). This is ideal from a performance perspective albeit perhaps a
bit unorthodox.

2. Intel compiler has a __regcall directive which allows ZMM registers to be
used for function arguments.

3. Visual Studio has the __vectorcall directive which does this for SSE & AVX.
Although it seems fairly obvious to me that this approach will eventually be
carried over to AVX512, it's uncertain when MSVC will actually support this
instruction set. Consider that even when doing nothing, Clang's __vectorcall
will be eventually be incompatible with what Microsoft deploys at that point.

I wonder: is it worth waiting for Microsoft here? IMHO it would make a lot more
sense to unlock __vectorcall for AVX512 arguments and revise the calling
conventions if/when Microsoft officially supports AVX512.

Thoughts?

Best,
Wenzel

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160814/4647951d/attachment-0001.html>