[Bug target/96895] New: ABI of returning V1DF differs between GCC and clang

[Bug target/96895] New: ABI of returning V1DF differs between GCC and clang

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

            Bug ID: 96895
           Summary: ABI of returning V1DF differs between GCC and clang
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

clang and GCC differ in returning v1df:

typedef double v1df __attribute__((vector_size(8)));
v1df foo (v1df x)
{
  return x;
}

clang returns in %xmm0 while GCC returns by invisible reference (thus in
memory).
v1df arguments are passed on the stack with both compilers.

GCC behaves this way because the v1df type has BLKmode.  If we assign
the type DFmode (V1DFmode is unavailable) then GCC passes and returns in %xmm0.
The target should likely not work on modes here but on types.

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
           Keywords|                            |ABI
                 CC|                            |hjl at gcc dot gnu.org,
                   |                            |matz at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I guess the psABI does not say anything about "non-standard" vector types. 
Note v1sf seems to be returned in %xmm0 with GCC but %eax with clang which
passes v1sf in general regs as well while GCC passes in %xmm0.

typedef float v1df __attribute__((vector_size(4)));
v1df foo (v1df x)
{
  return x;
}

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

--- Comment #2 from Michael Matz <matz at gcc dot gnu.org> ---
The psABI doesn't say anything about such types, no.  Maybe it could in some
additional info pages, but it's always a problem to codify behaviour
retroactively
in it, when conflicting implementations already exist.  It is about extension
types, though, so we might be fine.

FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for float
and clang behaviour for double is the most logical one: this extended type is
most
similar to a struct containing one float/double, and such are passed in XMM
registers per psABI.  As this is also consistent with how a single
top-level float is passed, this choice is the most consistent one.  This is
also
what the psABI _would_ say, if we had written it into it, so at least both
compilers would need a change to implement it.

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gitlab.com/x86-psAB
                   |                            |Is/x86-64-ABI/-/issues/1

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
I opened:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/1

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Michael Matz from comment #2)
> The psABI doesn't say anything about such types, no.  Maybe it could in some
> additional info pages, but it's always a problem to codify behaviour
> retroactively
> in it, when conflicting implementations already exist.  It is about
> extension types, though, so we might be fine.
> 
> FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for
> float and clang behaviour for double is the most logical one: this extended
> type is most
> similar to a struct containing one float/double, and such are passed in XMM
> registers per psABI.  As this is also consistent with how a single
> top-level float is passed, this choice is the most consistent one.  This is
> also
> what the psABI _would_ say, if we had written it into it, so at least both
> compilers would need a change to implement it.

It makes senses to me.  It isn't the first time that GCC changes the ABI.
This is why there is -Wabi is.

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Michael Matz from comment #2)
> The psABI doesn't say anything about such types, no.  Maybe it could in some
> additional info pages, but it's always a problem to codify behaviour
> retroactively
> in it, when conflicting implementations already exist.  It is about
> extension types, though, so we might be fine.
> 
> FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for
> float and clang behaviour for double is the most logical one: this extended
> type is most
> similar to a struct containing one float/double, and such are passed in XMM
> registers per psABI.  As this is also consistent with how a single
> top-level float is passed, this choice is the most consistent one.  This is
> also
> what the psABI _would_ say, if we had written it into it, so at least both
> compilers would need a change to implement it.

So vector types with element type T and N, a power-of-two, not otherwise
specified are passes the same as

struct S { T a[N] };

?  I guess there's mismatch then for AVX types with -mno-avx then at least
(AVX512 are probably too big to be passed in registers).

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> (In reply to Michael Matz from comment #2)
> > The psABI doesn't say anything about such types, no.  Maybe it could in some
> > additional info pages, but it's always a problem to codify behaviour
> > retroactively
> > in it, when conflicting implementations already exist.  It is about
> > extension types, though, so we might be fine.
> > 
> > FWIW, even ignoring the obvious relation of v1Xf to Xf, GCC behaviour for
> > float and clang behaviour for double is the most logical one: this extended
> > type is most
> > similar to a struct containing one float/double, and such are passed in XMM
> > registers per psABI.  As this is also consistent with how a single
> > top-level float is passed, this choice is the most consistent one.  This is
> > also
> > what the psABI _would_ say, if we had written it into it, so at least both
> > compilers would need a change to implement it.
> 
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
> 
> struct S { T a[N] };
> 
> ?  I guess there's mismatch then for AVX types with -mno-avx then at least
> (AVX512 are probably too big to be passed in registers).

Ugh.  We pass struct S { double a[4]; } in %rdi  _and_ on the stack?!  And
return by invisible reference _and_ in %eax?

typedef struct S { double a[4]; } v4df;

v4df foo (v4df x)
{
  return x;
}

foo:
.LFB0:
        .cfi_startproc
        movq    %rdi, %rax
        movdqu  8(%rsp), %xmm0
        movups  %xmm0, (%rdi)
        movdqu  24(%rsp), %xmm1
        movups  %xmm1, 16(%rdi)
        ret

but a two-element array is passed/returned in two %xmm regs

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

--- Comment #7 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
> So vector types with element type T and N, a power-of-two, not otherwise
> specified are passes the same as
> 
> struct S { T a[N] };
> 
> ?

No.  structs, if they are larger than 16 bytes are of class memory.  vector
types
larger than 16 bytes (which came only after the original psABI was written) are
passed different than the corresponding struct would have been (namely in the
appropriate vector registers, when those types are native to the hardware!).

That also explains your other observation:

> Ugh.  We pass struct S { double a[4]; } in %rdi  _and_ on the stack?!  And
> return by invisible reference _and_ in %eax?

Yes, a double[4] is larger than 16 bytes, hence memory, hence passed on the
stack
and returned via implicit reference.  You're mis-reading the assembler code
when
you think it's passed in %rdi and stack.  %rdi contains the address of the
caller
allocated return slot, i.e. the implicit reference.  %rax contains that same
address on return.

[Bug target/96895] ABI of returning V1DF differs between GCC and clang

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96895

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|https://gitlab.com/x86-psAB |
                   |Is/x86-64-ABI/-/issues/1    |
                 CC|                            |egallager at gcc dot gnu.org
           See Also|                            |https://gitlab.com/x86-psAB
                   |                            |Is/x86-64-ABI/-/issues/1

--- Comment #8 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #3)
> I opened:
> 
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/1

I'm moving this to the "See Also" field, now that that's possible.