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: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
