[RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Uros Bizjak]

[-- Attachment #1: Type: text/plain, Size: 2317 bytes --]

Hello!

I would like to propose an ABI adjustment for the aloha OSF/1 ABI. To
quote explanation in the patch:

--q--
  /* Pass float and _Complex float variable arguments by reference.
     This avoids 64-bit store from a FP register to a pretend args save area
     and subsequent 32-bit load from the saved location to a FP register.

     Note that 32-bit loads and stores to/from a FP register on alpha reorder
     bits to form a canonical 64-bit value in the FP register.  This fact
     invalidates compiler assumption that 32-bit FP value lives in the lower
     32-bits of the passed 64-bit FP value, so loading the 32-bit value from
     the stored 64-bit location using 32-bit FP load is invalid on alpha.

     This introduces sort of ABI incompatibility, but until _Float32 was
     introduced, C-family languages promoted 32-bit float variable arg to
     a 64-bit double, and it was not allowed to pass float as a varible
     argument.  Passing _Complex float as a variable argument never
     worked on alpha.  Thus, we have no backward compatibility issues
     to worry about, and passing un-promoted _Float32 and _Complex float
     as a variable argument will actually work in the future.  */
--/q--

Another rationale for the adjustment is, that "other" compilers do not
know about _Float32 and _Complex float, the official ABI pre-dates
some of these types by a decade or more (I was not able to find the
authoritative OSF/1 ABI document on the net...), and lastly ... gcc is
the last compiler that keeps this dead architecture alive, so IMO we
can consider it as a de-facto implementer of the ABI.

Following this ABI adjustment, we can also fix libffi, where
libffi.complex/cls_complex_va_float.c says:

--q--
/* Alpha splits _Complex into two arguments.  It's illegal to pass
   float through varargs, so _Complex float goes badly.  In sort of
   gets passed as _Complex double, but the compiler doesn't agree
   with itself on this issue.  */
/* { dg-do run { xfail alpha*-*-* } } */
--/q--

2016-09-02  Uros Bizjak  <ubizjak@gmail.com>

    * config/alpha/alpha.c (alpha_pass_by_reference): Pass un-named
    SFmode and SCmode arguments by reference.

Patch was bootstrapped and regression tested on alphaev68-linux-gnu
for all default languages plus obj-c++ and go.

Any comments?

Uros.

[-- Attachment #2: a.diff.txt --]
[-- Type: text/plain, Size: 1601 bytes --]

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 702cd27..81cef4e 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -5754,8 +5754,29 @@ static bool
 alpha_pass_by_reference (cumulative_args_t ca ATTRIBUTE_UNUSED,
 			 machine_mode mode,
 			 const_tree type ATTRIBUTE_UNUSED,
-			 bool named ATTRIBUTE_UNUSED)
+			 bool named)
 {
+  /* Pass float and _Complex float variable arguments by reference.
+     This avoids 64-bit store from a FP register to a pretend args save area
+     and subsequent 32-bit load from the saved location to a FP register.
+
+     Note that 32-bit loads and stores to/from a FP register on alpha reorder
+     bits to form a canonical 64-bit value in the FP register.  This fact
+     invalidates compiler assumption that 32-bit FP value lives in the lower
+     32-bits of the passed 64-bit FP value, so loading the 32-bit value from
+     the stored 64-bit location using 32-bit FP load is invalid on alpha.
+
+     This introduces sort of ABI incompatibility, but until _Float32 was
+     introduced, C-family languages promoted 32-bit float variable arg to
+     a 64-bit double, and it was not allowed to pass float as a varible
+     argument.  Passing _Complex float as a variable argument never
+     worked on alpha.  Thus, we have no backward compatibility issues
+     to worry about, and passing unpromoted _Float32 and _Complex float
+     as a variable argument will actually work in the future.  */
+
+  if (mode == SFmode || mode == SCmode)
+    return !named;
+
   return mode == TFmode || mode == TCmode;
 }
 

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Joseph Myers]

On Fri, 2 Sep 2016, Uros Bizjak wrote:

>      argument.  Passing _Complex float as a variable argument never
>      worked on alpha.  Thus, we have no backward compatibility issues

Presumably there should be an architecture-independent execution test of 
passing _Complex float in variable arguments - either new, or a 
pre-existing one whose XFAIL or skip for alpha can be removed.  (That is, 
one in the GCC testsuite rather than relying on a libffi test to test 
GCC.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Jakub Jelinek]

On Fri, Sep 02, 2016 at 12:09:30PM +0000, Joseph Myers wrote:
> On Fri, 2 Sep 2016, Uros Bizjak wrote:
> 
> >      argument.  Passing _Complex float as a variable argument never
> >      worked on alpha.  Thus, we have no backward compatibility issues
> 
> Presumably there should be an architecture-independent execution test of 
> passing _Complex float in variable arguments - either new, or a 
> pre-existing one whose XFAIL or skip for alpha can be removed.  (That is, 
> one in the GCC testsuite rather than relying on a libffi test to test 
> GCC.)

And if it is in g*.dg/compat/, it can even test ABI compatibility between
different compilers or their versions.

	Jakub

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Uros Bizjak]

On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Sep 02, 2016 at 12:09:30PM +0000, Joseph Myers wrote:
>> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>>
>> >      argument.  Passing _Complex float as a variable argument never
>> >      worked on alpha.  Thus, we have no backward compatibility issues
>>
>> Presumably there should be an architecture-independent execution test of
>> passing _Complex float in variable arguments - either new, or a
>> pre-existing one whose XFAIL or skip for alpha can be removed.  (That is,
>> one in the GCC testsuite rather than relying on a libffi test to test
>> GCC.)
>
> And if it is in g*.dg/compat/, it can even test ABI compatibility between
> different compilers or their versions.

It looks to me that we have no tests for _Complex float variable
arguments passing in g*.dg/compat/. There are no xfails for alpha* in
this directory, and these arguments would fail for sure for this
target.

Uros.

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Uros Bizjak]

On Fri, Sep 2, 2016 at 2:37 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Fri, Sep 02, 2016 at 12:09:30PM +0000, Joseph Myers wrote:
>>> On Fri, 2 Sep 2016, Uros Bizjak wrote:
>>>
>>> >      argument.  Passing _Complex float as a variable argument never
>>> >      worked on alpha.  Thus, we have no backward compatibility issues
>>>
>>> Presumably there should be an architecture-independent execution test of
>>> passing _Complex float in variable arguments - either new, or a
>>> pre-existing one whose XFAIL or skip for alpha can be removed.  (That is,
>>> one in the GCC testsuite rather than relying on a libffi test to test
>>> GCC.)
>>
>> And if it is in g*.dg/compat/, it can even test ABI compatibility between
>> different compilers or their versions.
>
> It looks to me that we have no tests for _Complex float variable
> arguments passing in g*.dg/compat/. There are no xfails for alpha* in
> this directory, and these arguments would fail for sure for this
> target.

Indeed. The only scalar _Complex float processing is in
scalar-by-value-4*, and the test lacks varargs.

Uros.

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Joseph Myers]

On Fri, 2 Sep 2016, Uros Bizjak wrote:

> It looks to me that we have no tests for _Complex float variable
> arguments passing in g*.dg/compat/. There are no xfails for alpha* in
> this directory, and these arguments would fail for sure for this
> target.

I suppose compat tests should be added for _Complex double and _Complex 
long double variable argument passing as well along with _Complex float, 
if those types aren't tested for variable argument passing either.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Mike Stump]

On Sep 2, 2016, at 6:31 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> 
> On Fri, 2 Sep 2016, Uros Bizjak wrote:
> 
>> It looks to me that we have no tests for _Complex float variable
>> arguments passing in g*.dg/compat/. There are no xfails for alpha* in
>> this directory, and these arguments would fail for sure for this
>> target.
> 
> I suppose compat tests should be added for _Complex double and _Complex 
> long double variable argument passing as well along with _Complex float, 
> if those types aren't tested for variable argument passing either.

I concur.

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Richard Henderson]

On 09/02/2016 02:35 AM, Uros Bizjak wrote:
> --q--
>   /* Pass float and _Complex float variable arguments by reference.
>      This avoids 64-bit store from a FP register to a pretend args save area
>      and subsequent 32-bit load from the saved location to a FP register.
> 
>      Note that 32-bit loads and stores to/from a FP register on alpha reorder
>      bits to form a canonical 64-bit value in the FP register.  This fact
>      invalidates compiler assumption that 32-bit FP value lives in the lower
>      32-bits of the passed 64-bit FP value, so loading the 32-bit value from
>      the stored 64-bit location using 32-bit FP load is invalid on alpha.
> 
>      This introduces sort of ABI incompatibility, but until _Float32 was
>      introduced, C-family languages promoted 32-bit float variable arg to
>      a 64-bit double, and it was not allowed to pass float as a varible
>      argument.  Passing _Complex float as a variable argument never
>      worked on alpha.  Thus, we have no backward compatibility issues
>      to worry about, and passing un-promoted _Float32 and _Complex float
>      as a variable argument will actually work in the future.  */
> --/q--

This sounds like a good plan to me.

> (I was not able to find the
> authoritative OSF/1 ABI document on the net...)

As far as I know, it was never available online.
I have a paper copy.


r~

Re: [RFC PATCH, alpha]: ABI change: pass SFmode and SCmode variable arguments by reference

[Uros Bizjak]

On Fri, Sep 2, 2016 at 7:17 PM, Richard Henderson <rth@twiddle.net> wrote:
> On 09/02/2016 02:35 AM, Uros Bizjak wrote:
>> --q--
>>   /* Pass float and _Complex float variable arguments by reference.
>>      This avoids 64-bit store from a FP register to a pretend args save area
>>      and subsequent 32-bit load from the saved location to a FP register.
>>
>>      Note that 32-bit loads and stores to/from a FP register on alpha reorder
>>      bits to form a canonical 64-bit value in the FP register.  This fact
>>      invalidates compiler assumption that 32-bit FP value lives in the lower
>>      32-bits of the passed 64-bit FP value, so loading the 32-bit value from
>>      the stored 64-bit location using 32-bit FP load is invalid on alpha.
>>
>>      This introduces sort of ABI incompatibility, but until _Float32 was
>>      introduced, C-family languages promoted 32-bit float variable arg to
>>      a 64-bit double, and it was not allowed to pass float as a varible
>>      argument.  Passing _Complex float as a variable argument never
>>      worked on alpha.  Thus, we have no backward compatibility issues
>>      to worry about, and passing un-promoted _Float32 and _Complex float
>>      as a variable argument will actually work in the future.  */
>> --/q--
>
> This sounds like a good plan to me.

Thanks!

>> (I was not able to find the
>> authoritative OSF/1 ABI document on the net...)
>
> As far as I know, it was never available online.
> I have a paper copy.

FYI, after some more involved deep searching (and luck ;) I found one
at [1]. It is under "Programming Documentation Bookshelf" section, the
document is called "Calling Standard for Alpha Systems" [2].

[1] http://h41361.www4.hpe.com/docs/pub_page/V51B_DOCS/v51b_doclist.htm
[2] http://h41361.www4.hpe.com/docs/base_doc/DOCUMENTATION/V51B_ACRO_DUX/ARH9MCTE.PDF

Uros.