[PATCH] x86-64 ABI: unwrap single element structs / arrays of 256-bit vectors to pass and return in registers

[Sanjay Patel]

Thanks, HJ.
I posted a question here:
https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/k9lgQogMZqw

On Mon, Feb 16, 2015 at 10:13 AM, H.J. Lu <hjl.tools at gmail.com> wrote:

> On Mon, Feb 16, 2015 at 8:40 AM, hfinkel at anl.gov <hfinkel at anl.gov> wrote:
> > In http://reviews.llvm.org/D7614#124323, @spatel wrote:
> >
> >> In http://reviews.llvm.org/D7614#124120, @hfinkel wrote:
> >>
> >> > What happens when you try to pass a struct of { v4f32 x[2]; }?
> >>
> >>
> >> Great question. There's a check in classify() around here:
> >>
> https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/TargetInfo.cpp#L2044
> >>
> >>   // The only case a 256-bit wide vector could be used is when the
> struct
> >>   // contains a single 256-bit element. Since Lo and Hi logic isn't
> extended
> >>   // to work for sizes wider than 128, early check and fallback to
> memory.
> >>   //
> >>   if (Size > 128 && getContext().getTypeSize(i->getType()) != 256) {
> >>
> >>
> >> And so we don't try to pass/return anything in registers with an array
> of two 128-bit vectors.
> >>
> >> And this also triggers on the even simpler case of:
> >>  struct v4f32_wrapper {
> >>
> >>   v4f32 v1;
> >>   v4f32 v2;
> >>
> >> };
> >>
> >> Based on my reading of the ABI, I would've thought that could be passed
> as 2 xmm registers, but we pass by memory for this too. FWIW, gcc 4.9 and
> icc 15 do the same in these cases, so I think this is just the way things
> are supposed to be.
> >
> >
> > Okay, great. Please commit.
> >
> > Also, if the ABI spec differs from implementation practice, we should
> also send a note to whomever maintains that and try to get it clarified.
> >
>
> All x86-64 psABI questions should go to
>
> https://groups.google.com/forum/#!forum/x86-64-abi
>
>
> --
> H.J.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150216/e2fa5f4b/attachment.html>