[PATCH] D108887: [X86][MS] Fix the aligement mismatch of vector variable arguments on Win32

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 3 13:50:15 PDT 2021


rnk added inline comments.


================
Comment at: llvm/lib/Target/X86/X86CallingConv.td:29-30
+    : CCIf<"State.isVarArg() && "
+           "State.getMachineFunction().getSubtarget().getTargetTriple()."
+           "isOSWindows()",
+           A>;
----------------
mstorsjo wrote:
> rnk wrote:
> > pengfei wrote:
> > > rnk wrote:
> > > > Please check what mingw does in this case.
> > > With this patch, mingw also uses 4 bytes alignment for both caller and callee.
> > > But I'm not sure if it is the correct approach since I don't have a mingw environment to test.
> > > @LiuChen3 fixed Linux 32 bits problem in D78564 by changing callee's alignment to the vector size. Not sure if we should fix in that way.
> > @mstorsjo , do you mind checking what GCC does on Windows here? Mainly I'm looking out for the possibility that GCC passes such vectors indirectly when passed through varargs.
> Sorry for the delay. I checked the testcase from Compiler Explorer with GCC targeting mingw (10.2), and I get this:
> 
> ```
> __Z8testm128iz:
>         pushl   %ebp
>         movl    %esp, %ebp
>         leal    27(%ebp), %eax
>         andl    $-16, %eax
>         vmovups (%eax), %xmm0
>         vmovups %xmm0, _res1
>         movl    8(%ebp), %eax
>         popl    %ebp
>         ret
> [...]
> __Z17testPastArgumentsv:
>         pushl   %ebp
>         movl    %esp, %ebp
>         andl    $-16, %esp
>         subl    $32, %esp
>         vmovups _a, %xmm0
>         vmovups %xmm0, 16(%esp)
>         movl    $1, (%esp)
>         call    __Z8testm128iz
>         leave
>         ret
> ```
> 
> So based on that, I'd say that GCC consistently aligns them as a caller, and considers them aligned as a callee. So to be compatible, we'd need to do things the other way for mingw targets.
> 
> Then again, I guess such a thing could be considered a calling convention bug in GCC which might be fixable too (with a minor ABI break, but I guess such cases are rare in practice), and I'm not sure if they care about being calling convention compatible with MSVC regarding vector arguments either.
> 
No problem, I think this just means we should tweak this `isOSWindows` condition to `isWindowsMSVCEnvironment`.

How do I test mingw on compiler explorer? That would be handy for me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108887/new/

https://reviews.llvm.org/D108887



More information about the llvm-commits mailing list