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  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.

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

[Mike Stump]

On Sep 2, 2016, at 6:31 AM, Joseph Myers  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

[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
jos...@codesourcery.com

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  wrote:
> On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek  wrote:
>> On Fri, Sep 02, 2016 at 12:09:30PM +, 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

[Uros Bizjak]

On Fri, Sep 2, 2016 at 2:11 PM, Jakub Jelinek  wrote:
> On Fri, Sep 02, 2016 at 12:09:30PM +, 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

[Jakub Jelinek]

On Fri, Sep 02, 2016 at 12:09:30PM +, 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

[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
jos...@codesourcery.com