rnk marked 2 inline comments as done.
rnk added inline comments.
================
Comment at: clang/test/CodeGen/x86_32-arguments-win32.c:77
+// CHECK-LABEL: define dso_local void @receive_vec_256(<8 x float> inreg %x,
<8 x float> inreg %y, <8 x float> inreg %z, <8 x float>* %0, <8 x float>* %1)
+// CHECK-LABEL: define dso_local void @receive_vec_512(<16 x float> inreg %x,
<16 x float> inreg %y, <16 x float> inreg %z, <16 x float>* %0, <16 x float>*
%1)
+// CHECK-LABEL: define dso_local void @receive_vec_1024(<32 x float>* %0, <32
x float>* %1, <32 x float>* %2, <32 x float>* %3, <32 x float>* %4)
----------------
craig.topper wrote:
> What happens in the backend with inreg if 512-bit vectors aren't legal?
LLVM splits the vector up using the largest legal vector size. As many pieces
as possible are passed in available XMM/YMM registers, and the rest are passed
in memory. MSVC, of course, assumes the user wanted the larger vector size, and
uses whatever vector instructions it needs to move the arguments around.
Previously, I advocated for a model where calling an Intel intrinsic function
had the effect of implicitly marking the caller with the target attributes of
the intrinsic. This falls down if the user tries to write a single function
that conditionally branches between code that uses different instruction set
extensions. You can imagine the SSE2 codepath accidentally using AVX
instructions because the compiler thinks they are better. I'm told that ICC
models CPU micro-architectural features in the CFG, but I don't ever expect
that LLVM will do that. If we're stuck with per-function CPU feature settings,
it seems like it would be nice to try to do what the user asked by default, and
warn the user if we see them doing a cpuid check in a function that has been
implicitly blessed with some target attributes. You could imagine doing a
similar thing when large vector type variables are used: if a large vector
argument or local is used, implicitly enable the appropriate target features to
move vectors of that size around.
This idea didn't get anywhere, and the current situation has persisted.
---
You know, maybe we should just keep clang the way it is, and just set up a
warning in the backend that says "hey, I split your large vector. You probably
didn't want that." And then we just continue doing what we do now. Nobody likes
backend warnings, but it seems better than the current direction of the
frontend knowing every detail of x86 vector extensions.
================
Comment at: clang/test/CodeGenCXX/inalloca-vector.cpp:71
+// CHECK-LABEL: define dso_local x86_vectorcallcc void
@"?vectorcall_receive_vec@@Y{{[^"]*}}"
+// CHECKX-SAME: (double inreg %xmm0,
+// CHECKX-SAME: double inreg %xmm1,
----------------
erichkeane wrote:
> Are all the checks hre on out disabled for a reason?
Yes, this is case 2 in the commit message. I won't close the bug without coming
back to this.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72114/new/
https://reviews.llvm.org/D72114
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
