Re: [PATCH 2/3] Make __float128 use the _Float128 type, PR target/107299

["Kewen.Lin" <linkw@linux.ibm.com>]

on 2022/12/14 18:33, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 06:11:26PM +0800, Kewen.Lin wrote:
>>> The hacks with different precisions of powerpc 128-bit floating types are
>>> very unfortunate, it is I assume because the middle-end asserted that scalar
>>> floating point types with different modes have different precision.
>>> We no longer assert that, as BFmode and HFmode (__bf16 and _Float16) have
>>> the same 16-bit precision as well and e.g. C++ FE knows to treat standard
>>> vs. extended floating point types vs. other unknown floating point types
>>> differently in finding result type of binary operations or in which type
>>> comparisons will be done.  
>>
>> It's good news, for now those three long double modes on Power have different
>> precisions, if they can have the same precision, I'd expect the ICE should be
>> gone.
> 
> I'm talking mainly about r13-3292, the asserts now check different modes
> have different precision unless it is half vs. brain or vice versa, but
> could be changed further, but if the precision is the same, the FEs
> and the middle-end needs to know how to deal with those.
> For C++23, say when __ibm128 is the same as long double and _Float128 is
> supported, the 2 types are unordered (neither is a subset or superset of
> the other because there are many _Float128 values one can't represent
> in double double (whether anything with exponent larger than what double
> can represent or most of the more precise values), but because of the
> variable precision there are double double values that can't be represented
> in _Float128 either) and so we can error on comparisons of those or on
> arithmetics with such arguments (unless explicitly converted first).
> But for backwards compatibility we can't do that for __float128 vs. __ibm128
> and so need to backwards compatibly decide what wins.  And for the
> middle-end say even for mode conversions decide what is widening and what is
> narrowing even when they are unordered.

Thanks for the pointer!  I don't have good understanding on the backwards
compatibility on those conversions, guessing Mike, Segher and David would have
more insights.

BR,
Kewen