Hi!

On Wed, Dec 14, 2022 at 10:36:03AM +0100, Jakub Jelinek wrote:
> On Wed, Dec 14, 2022 at 04:46:07PM +0800, Kewen.Lin via Gcc-patches wrote:
> > Since function useless_type_conversion_p considers two float types are 
> > compatible
> > if they have the same mode, so it doesn't require the explicit conversions 
> > between
> > these two types.  I think it's exactly what we want.  And to me, it looks 
> > unexpected
> > to have two types with the same mode but different precision.
> > 
> > So could we consider disabling the above workaround to make _Float128 have 
> > the same
> > precision as __float128 (long double) (the underlying TFmode)?  I tried the 
> > below
> > change:
> 
> 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.

IEEE QP and double-double cannot be ordered, neither represents a subset
of the other.  But the current middle end does require a total ordering
for all floating point types (that can be converted to each other).

Mike's precision hack was supposed to give us some time until an actual
fix was made.  But no one has worked on that, and there have been
failures found with the precision hack as well, it worked remarkably
well but it isn't perfect.

We cannot move forward in a meaningful way until these problems are
fixed.  We can move around like headless chickens some more of course.


Segher

Reply via email to