Re: [PATCH 2/3 V2] Do not include stdio.h in libgcc's Decimal/Float128 conversions.

[Michael Meissner <meissner@linux.ibm.com>]

On Wed, Mar 03, 2021 at 11:33:52PM +0000, Joseph Myers wrote:
> On Wed, 3 Mar 2021, Michael Meissner via Gcc-patches wrote:
> 
> > As we have discussed many times, on 32-bit BE, you cannot use hardware
> > _Float128 support on power9/power10 because there is no TImode in 32-bit.
> > Various machine independent parts of GCC require an integer type to be the same
> > size as basic types.  If somebody made TImode work, we can remove the
> > restriction and allow _Float128 to work on 32-bit.
> 
> I'm not sure exactly what the machine-independent requirement is, but 
> _Float128 is supported for 32-bit x86, riscv, sparc and s390 at least.
> 
> There's no support for _Float128 in the 32-bit powerpc ABI, but I don't 
> think there is anything architecture-independent preventing such support 
> on 32-bit platforms where TImode is unsupported (i.e. not supported by the 
> scalar_mode_supported_p hook).

The problem is several parts of GCC insists that there be an integer MODE that
is the same size as the scalar MODE.  I recall it happens in moves (such as
during calls), but it could be other places as well.

In theory, it would be nice to get this fixed, but the practicality is you can
go down a lot of places to find the next bug and fix that.

Maybe there is somebody who has enough time and patience to fix all of the
places that demand that there be an integer type large enough to hold scalar
types like _Float128 and generate alternate code.

Or perhaps implement enough of TImode so that it doesn't cause issues.

But in order to do the work and make sure it does not cause issues for 32-bit
and hardware _Float128, you need to build on a big endian power9 system.  In
the compile farm there is gcc135, but it is run little endian.

BTW, during the initial development of MMA, I ran into the same issue for the
vector pair and vector quad types.  Each of the approaches that we took had
some serious issues.  What I did in the initial stages of development is add
dummy moves that would never succeed for 256 and 512-bit integers, and then use
partial integers to represent that these weren't quite real integers.  However,
even then we discovered various parts of the compiler would strip off the
partial integer type and use the full integer type, even though there was no
real support for that type.  Peter and Aaron eventually solved this by adding
support for opaque modes.

However, Float128 needs to be a scalar floating point mode, not an opaque mode.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.ibm.com, phone: +1 (978) 899-4797