On Wed, Dec 21, 2022 at 09:40:24PM +0000, Joseph Myers wrote: > On Wed, 21 Dec 2022, Segher Boessenkool wrote: > > > > --- a/gcc/tree.cc > > > +++ b/gcc/tree.cc > > > @@ -9442,15 +9442,6 @@ build_common_tree_nodes (bool signed_char) > > > if (!targetm.floatn_mode (n, extended).exists (&mode)) > > > continue; > > > int precision = GET_MODE_PRECISION (mode); > > > - /* Work around the rs6000 KFmode having precision 113 not > > > - 128. */ > > > > It has precision 126 now fwiw. > > > > Joseph: what do you think about this patch? Is the workaround it > > removes still useful in any way, do we need to do that some other way if > > we remove this? > > I think it's best for the TYPE_PRECISION, for any type with the binary128 > format, to be 128 (not 126). > > It's necessary that _Float128, _Float64x and long double all have the same > TYPE_PRECISION when they have the same (binary128) format, or at least > that TYPE_PRECISION for _Float128 >= that for long double >= that for > _Float64x, so that the rules in c_common_type apply properly. > > How the TYPE_PRECISION compares to that of __ibm128, or of long double > when that's double-double, is less important.
I spent a few days on working on this. I have patches to make the 3 128-bit types to all have TYPE_PRECISION of 128. To do this, I added a new mode macro (FRACTIONAL_FLOAT_MODE_NO_WIDEN) that takes the same arguments as FRACTIONAL_FLOAT_MODE. This will create a floating point mode that is a normal floating point mode, but the GET_MODE_WIDER and GET_MODE_2XWIDER macros will never return it. By declaring both IFmode and KFmode to not be widened to, but noral TFmode is, it eliminates the problems where an IBM expression got converted to IEEE, which can mostly (but not always) contain the value. In addition, on power8, it means it won't call the KF mode emulator functions, just the IF functions. We need to have one 128-bit mode (TFmode) that is not declared as NO_WARN, or long double won't be created, since float_mode_for_size (128) will not be able to find the correct type. I did have to patch convert_mode_scalar so that it would not abort if it was doing a conversion between two floating point types with the same precision. I tested this with the first patch from the previous set of patches (that rewrites complex multiply/divide built-in setup). I think that patch is useful as a stand alone patch. I also used Kewen Lin's patch from December 27th in build_common_tree_nodes to do the test. I haven't tested if this particular patch fixes this problem, or it fixes something else. Finally, I used the third patch in my series of patches that straightens out 128<->128 FP conversions. That patch needed to be tweaked slightly, as one of the conversations became FLOAT_EXTEND instead of FLOAT_TRUNCATE. We don't have a RTL operation that says convert from one floating point type to another where both types are the same size. Whether FLOAT_EXTEND is used or FLOAT_TRUNCATE, used to depend on whether the TYPE_PRECISION was greater or lesser. Now that they are the same, it arbitrarily picks FLOAT_EXTEND. While I still think the 2nd patch is important, it isn't needed with the above patches. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
