This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc
- From: Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, David Edelsohn <dje dot gcc at gmail dot com>
- Date: Mon, 27 Jun 2016 12:42:40 -0500
- Subject: Re: [PATCH, rs6000] Add minimum __float128 built-in support required for glibc
- Authentication-results: sourceware.org; auth=none
- References: <62B0D9C8-A6C4-4000-B409-0627F854F6DC at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606222024020 dot 22324 at digraph dot polyomino dot org dot uk> <2BD1312F-1CB3-4B43-AC09-BFF01356FFA6 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606222315140 dot 22324 at digraph dot polyomino dot org dot uk> <17B9C035-0FF7-4631-8C95-3E50F4E1AB1D at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1606231115420 dot 21240 at digraph dot polyomino dot org dot uk> <87shvypm1f dot fsf at googlemail dot com>
> On Jun 27, 2016, at 12:41 PM, Richard Sandiford <rdsandiford@googlemail.com> wrote:
>
> Joseph Myers <joseph@codesourcery.com> writes:
>> On Wed, 22 Jun 2016, Bill Schmidt wrote:
>>> 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.
>
> Yeah, I don't think we should have named patterns to generate constants.
> We should send the constant through the normal move patterns and make
> the expander or move define_insns handle them appropriately.
Agreed. We'll plan on working the various interesting constants into the handling of the move insns.
Bill
>
> Thanks,
> Richard
>