Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 22 Jun 2016, Bill Schmidt wrote:

> I understand that this is what we want for GCC 7.  My current concern is to
> get my patch included in GCC 6.2, where I can't be polluting common code.
> To get it accepted there, I first need this code approved in mainline.  So I
> am quite willing to move to the architecture-independent ones later, but
> for now I don't see that I have any choice but to seek approval for the
> purely arch-dependent one.

I don't think it's sensible to choose implementation approaches on 
mainline based on possible backports.

It seems clear to me that the architecture-independent approach is the 
right one for mainline.  This may mean the backport has some 
architecture-specific code that's not on mainline (along with code, to 
optimize copysign/fabs expansion, that may be relevant in both places), 
but that shouldn't influence the choice of how to do things on mainline.

It looks rather like this proposed code would not in fact result in 
__builtin_inff128 or __builtin_huge_valf128 suitable for glibc use - 
there's no folding support for them so they wouldn't be usable in static 
initializers.  (This can be worked around, as would be necessary anyway 
for __float128 support in glibc for x86_64 with existing GCC releases - 
some internal header would define __builtin_inff128() to ((__float128) 
__builtin_inf ()) for older compilers.)

Until the glibc support is actually tested, reviewed and fully functional, 
it would not surprise me at all if there are other back-end bugs in GCC 6 
that need fixing for it to be usable to build or use such support in 
glibc, or other features needed that we haven't realised are needed.

> The fact that I hook this built-in directly to a pattern named infkf1
> doesn't seem to preclude anything you suggest.  I named it this way
> on the off-chance that inf<m>1 becomes a standard pattern in the
> future, in which case I want to generate this constant.  We can 
> always use gen_infkf1 to reuse this code in any other context.  I'm
> not understanding your objection.

That expander pattern is not useful given a target-independent built-in 
__builtin_inff128, since it will never be used except by a built-in 
function specifically associated with it.

I don't know what code will be generated for a use of _Float128 infinity, 
from the target-independent code - or, right now, for a use of 
(__float128) __builtin_inf ().  But if it's not the code you want, any 
reasonable fix would not be restricted to the case where __builtin_inff128 
() is used - it would work equally well for any case where that constant 
bit-pattern is wanted in VSX registers.

-- 
Joseph S. Myers
joseph@codesourcery.com