public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/meissner/heads/dmf004-orig)] Update ChangeLog.meissner.
@ 2022-11-17 21:50 Michael Meissner
0 siblings, 0 replies; 2+ messages in thread
From: Michael Meissner @ 2022-11-17 21:50 UTC (permalink / raw)
To: gcc-cvs
https://gcc.gnu.org/g:0780acb9266b1489763c218c9c39dd65cfa2724b
commit 0780acb9266b1489763c218c9c39dd65cfa2724b
Author: Michael Meissner <meissner@linux.ibm.com>
Date: Wed Nov 9 00:35:25 2022 -0500
Update ChangeLog.meissner.
2022-11-09 Michael Meissner <meissner@linux.ibm.com>
gcc/
* ChangeLog.meissner: Update.
Diff:
---
gcc/ChangeLog.meissner | 332 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 332 insertions(+)
diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
new file mode 100644
index 00000000000..2387b2033c7
--- /dev/null
+++ b/gcc/ChangeLog.meissner
@@ -0,0 +1,332 @@
+==================== Dmf004-orig branch, patch #4.
+
+Patch libgcc to always use _Float128 and _Complex _Float128 on PowerPC.
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+libgcc/
+
+ * config/rs6000/quad-float128.h (TF): Delete definition.
+ (TFtype): Define to be _Float128.
+ (TCtype): Change to be _Complex _Float128.
+ * libgcc2.h (TFtype): Allow MD code to override definition.
+ (TCtype): Likewise.
+ * soft-fp/quad.h (TFtype): Likewise.
+
+==================== Dmf004-orig branch, patch #3.
+
+Update float 128-bit conversions, PR target/107299.
+
+This patch fixes two tests that are still failing when long double is IEEE
+128-bit after the previous 2 patches for PR target/107299 have been applied.
+The tests are:
+
+ gcc.target/powerpc/convert-fp-128.c
+ gcc.target/powerpc/pr85657-3.c
+
+This patch is a rewrite of the patch submitted on August 18th:
+
+| https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599988.html
+
+This patch reworks the conversions between 128-bit binary floating point types.
+Previously, we would call rs6000_expand_float128_convert to do all conversions.
+Now, we only define the conversions between the same representation that turn
+into a NOP. The appropriate extend or truncate insn is generated, and after
+register allocation, it is converted to a move.
+
+This patch also fixes two places where we want to override the external name
+for the conversion function, and the wrong optab was used. Previously,
+rs6000_expand_float128_convert would handle the move or generate the call as
+needed. Now, it lets the machine independent code generate the call. But if
+we use the machine independent code to generate the call, we need to update the
+name for two optabs where a truncate would be used in terms of converting
+between the modes. This patch updates those two optabs.
+
+I tested this patch on:
+
+ 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+ 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+ 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm
+ 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm
+
+In the past I have also tested this exact patch on the following systems:
+
+ 1) LE Power10 using --with-cpu=power9 --with-long-double-format=ibm
+ 2) LE Power10 using --with-cpu=power8 --with-long-double-format=ibm
+ 3) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+
+There were no regressions in the bootstrap process or running the tests (after
+applying all 3 patches for PR target/107299). Can I check this patch into the
+trunk?
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+gcc/
+
+ PR target/107299
+ * config/rs6000/rs6000.cc (init_float128_ieee): Use the correct
+ float_extend or float_truncate optab based on how the machine converts
+ between IEEE 128-bit and IBM 128-bit.
+ * config/rs6000/rs6000.md (IFKF): Delete.
+ (IFKF_reg): Delete.
+ (extendiftf2): Rewrite to be a move if IFmode and TFmode are both IBM
+ 128-bit. Do not run if TFmode is IEEE 128-bit.
+ (extendifkf2): Delete.
+ (extendtfkf2): Delete.
+ (extendtfif2): Delete.
+ (trunciftf2): Delete.
+ (truncifkf2): Delete.
+ (trunckftf2): Delete.
+ (extendkftf2): Implement conversion of IEEE 128-bit types as a move.
+ (trunctfif2): Delete.
+ (trunctfkf2): Implement conversion of IEEE 128-bit types as a move.
+ (extend<mode>tf2_internal): Delete.
+ (extendtf<mode>2_internal): Delete.
+
+==================== Dmf004-orig branch, patch #2.
+
+Make __float128 use the _Float128 type, PR target/107299.
+
+This patch fixes the issue that GCC cannot build when the default long double
+is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
+to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc
+during the evrp pass. Ultimately it is failing because the code declared the
+type to use TFmode but it used F128 functions (i.e. KFmode).
+
+ typedef float TFtype __attribute__((mode (TF)));
+ typedef __complex float TCtype __attribute__((mode (TC)));
+
+ TCtype
+ __mulkc3_sw (TFtype a, TFtype b, TFtype c, TFtype d)
+ {
+ TFtype ac, bd, ad, bc, x, y;
+ TCtype res;
+
+ ac = a * c;
+ bd = b * d;
+ ad = a * d;
+ bc = b * c;
+
+ x = ac - bd;
+ y = ad + bc;
+
+ if (__builtin_isnan (x) && __builtin_isnan (y))
+ {
+ _Bool recalc = 0;
+ if (__builtin_isinf (a) || __builtin_isinf (b))
+ {
+
+ a = __builtin_copysignf128 (__builtin_isinf (a) ? 1 : 0, a);
+ b = __builtin_copysignf128 (__builtin_isinf (b) ? 1 : 0, b);
+ if (__builtin_isnan (c))
+ c = __builtin_copysignf128 (0, c);
+ if (__builtin_isnan (d))
+ d = __builtin_copysignf128 (0, d);
+ recalc = 1;
+ }
+ if (__builtin_isinf (c) || __builtin_isinf (d))
+ {
+
+ c = __builtin_copysignf128 (__builtin_isinf (c) ? 1 : 0, c);
+ d = __builtin_copysignf128 (__builtin_isinf (d) ? 1 : 0, d);
+ if (__builtin_isnan (a))
+ a = __builtin_copysignf128 (0, a);
+ if (__builtin_isnan (b))
+ b = __builtin_copysignf128 (0, b);
+ recalc = 1;
+ }
+ if (!recalc
+ && (__builtin_isinf (ac) || __builtin_isinf (bd)
+ || __builtin_isinf (ad) || __builtin_isinf (bc)))
+ {
+
+ if (__builtin_isnan (a))
+ a = __builtin_copysignf128 (0, a);
+ if (__builtin_isnan (b))
+ b = __builtin_copysignf128 (0, b);
+ if (__builtin_isnan (c))
+ c = __builtin_copysignf128 (0, c);
+ if (__builtin_isnan (d))
+ d = __builtin_copysignf128 (0, d);
+ recalc = 1;
+ }
+ if (recalc)
+ {
+ x = __builtin_inff128 () * (a * c - b * d);
+ y = __builtin_inff128 () * (a * d + b * c);
+ }
+ }
+
+ __real__ res = x;
+ __imag__ res = y;
+ return res;
+ }
+
+Currently GCC uses the long double type node for __float128 if long double is
+IEEE 128-bit. It did not use the node for _Float128.
+
+Originally this was noticed if you call the nansq function to make a signaling
+NaN (nansq is mapped to nansf128). Because the type node for _Float128 is
+different from __float128, the machine independent code converts signaling NaNs
+to quiet NaNs if the types are not compatible. The following tests used to
+fail when run on a system where long double is IEEE 128-bit:
+
+ gcc.dg/torture/float128-nan.c
+ gcc.target/powerpc/nan128-1.c
+
+This patch makes both __float128 and _Float128 use the same type node.
+
+One side effect of not using the long double type node for __float128 is that we
+must only use KFmode for _Float128/__float128. The libstdc++ library won't
+build if we use TFmode for _Float128 and __float128 when long double is IEEE
+128-bit.
+
+Another minor side effect is that the f128 round to odd fused multiply-add
+function will not merge negatition with the FMA operation when the type is long
+double. If the type is __float128 or _Float128, then it will continue to do the
+optimization. The round to odd functions are defined in terms of __float128
+arguments. For example:
+
+ long double
+ do_fms (long double a, long double b, long double c)
+ {
+ return __builtin_fmaf128_round_to_odd (a, b, -c);
+ }
+
+will generate (assuming -mabi=ieeelongdouble):
+
+ xsnegqp 4,4
+ xsmaddqpo 4,2,3
+ xxlor 34,36,36
+
+while:
+
+ __float128
+ do_fms (__float128 a, __float128 b, __float128 c)
+ {
+ return __builtin_fmaf128_round_to_odd (a, b, -c);
+ }
+
+will generate:
+
+ xsmsubqpo 4,2,3
+ xxlor 34,36,36
+
+I tested all 3 patchs for PR target/107299 on:
+
+ 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+ 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+ 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm
+ 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm
+
+Once all 3 patches have been applied, we can once again build GCC when long
+double is IEEE 128-bit. There were no other regressions with these patches.
+Can I check these patches into the trunk?
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+gcc/
+
+ PR target/107299
+ * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Always use the
+ _Float128 type for __float128.
+ (rs6000_expand_builtin): Only change a KFmode built-in to TFmode, if the
+ built-in passes or returns TFmode. If the predicate failed because the
+ modes were different, use convert_move to load up the value instead of
+ copy_to_mode_reg.
+ * config/rs6000/rs6000.cc (rs6000_translate_mode_attribute): Don't
+ translate IEEE 128-bit floating point modes to explicit IEEE 128-bit
+ modes (KFmode or KCmode), even if long double is IEEE 128-bit.
+ (rs6000_libgcc_floating_mode_supported_p): Support KFmode all of the
+ time if we support IEEE 128-bit floating point.
+ (rs6000_floatn_mode): _Float128 and _Float128x always uses KFmode.
+
+gcc/testsuite/
+
+ PR target/107299
+ * gcc.target/powerpc/float128-hw12.c: New test.
+ * gcc.target/powerpc/float128-hw13.c: Likewise.
+ * gcc.target/powerpc/float128-hw4.c: Update insns.
+
+==================== Dmf004-orig branch, patch #1.
+
+Rework 128-bit complex multiply and divide.
+
+This function reworks how the complex multiply and divide built-in functions are
+done. Previously we created built-in declarations for doing long double complex
+multiply and divide when long double is IEEE 128-bit. The old code also did not
+support __ibm128 complex multiply and divide if long double is IEEE 128-bit.
+
+In terms of history, I wrote the original code just as I was starting to test
+GCC on systems where IEEE 128-bit long double was the default. At the time, we
+had not yet started mangling the built-in function names as a way to bridge
+going from a system with 128-bit IBM long double to 128-bin IEEE long double.
+
+The original code depends on there only being two 128-bit types invovled. With
+the next patch in this series, this assumption will no longer be true. When
+long double is IEEE 128-bit, there will be 2 IEEE 128-bit types (one for the
+explicit __float128/_Float128 type and one for long double).
+
+The problem is we cannot create two separate built-in functions that resolve to
+the same name. This is a requirement of add_builtin_function and the C front
+end. That means for the 3 possible modes (IFmode, KFmode, and TFmode), you can
+only use 2 of them.
+
+This code does not create the built-in declaration with the changed name.
+Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
+before it is written out to the assembler file like it now does for all of the
+other long double built-in functions.
+
+We need to disable using this mapping when we are building libgcc, specifically
+when it is building the floating point 128-bit multiply and divide functions.
+The flag that is used when libgcc is built (-fbuilding-libcc) is only available
+in the C/C++ front ends. We need to remember that we are building libgcc in the
+rs6000-c.cc support to be able to use this later to decided whether to mangle
+the decl assembler name or not.
+
+When I wrote these patches, I discovered that __ibm128 complex multiply and
+divide had originally not been supported if long double is IEEE 128-bit as it
+would generate calls to __mulic3 and __divic3. I added tests in the testsuite
+to verify that the correct name (i.e. __multc3 and __divtc3) is used in this
+case.
+
+I tested all 3 patchs for PR target/107299 on:
+
+ 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+ 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+ 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm
+ 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm
+
+Once all 3 patches have been applied, we can once again build GCC when long
+double is IEEE 128-bit. There were no other regressions with these patches.
+Can I check these patches into the trunk?
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+gcc/
+
+ PR target/107299
+ * config/rs6000/rs6000-c.cc (rs6000_cpu_cpp_builtins): Set
+ building_libgcc.
+ * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
+ (init_float128_ieee): Delete code to switch complex multiply and divide
+ for long double.
+ (complex_multiply_builtin_code): New helper function.
+ (complex_divide_builtin_code): Likewise.
+ (rs6000_mangle_decl_assembler_name): Add support for mangling the name
+ of complex 128-bit multiply and divide built-in functions.
+ * config/rs6000/rs6000.opt (building_libgcc): New target variable.
+
+gcc/testsuite/
+
+ PR target/107299
+ * gcc.target/powerpc/divic3-1.c: New test.
+ * gcc.target/powerpc/divic3-2.c: Likewise.
+ * gcc.target/powerpc/mulic3-1.c: Likewise.
+ * gcc.target/powerpc/mulic3-2.c: Likewise.
+
+==================== Dmf004-orig branch, head.
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+ Clone branch
^ permalink raw reply [flat|nested] 2+ messages in thread
* [gcc(refs/users/meissner/heads/dmf004-orig)] Update ChangeLog.meissner.
@ 2022-11-09 5:35 Michael Meissner
0 siblings, 0 replies; 2+ messages in thread
From: Michael Meissner @ 2022-11-09 5:35 UTC (permalink / raw)
To: gcc-cvs
https://gcc.gnu.org/g:979b7e6996a0195a9cb3d5ead3e6359c230558e7
commit 979b7e6996a0195a9cb3d5ead3e6359c230558e7
Author: Michael Meissner <meissner@linux.ibm.com>
Date: Wed Nov 9 00:35:25 2022 -0500
Update ChangeLog.meissner.
2022-11-09 Michael Meissner <meissner@linux.ibm.com>
gcc/
* ChangeLog.meissner: Update.
Diff:
---
gcc/ChangeLog.meissner | 332 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 332 insertions(+)
diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
new file mode 100644
index 00000000000..2387b2033c7
--- /dev/null
+++ b/gcc/ChangeLog.meissner
@@ -0,0 +1,332 @@
+==================== Dmf004-orig branch, patch #4.
+
+Patch libgcc to always use _Float128 and _Complex _Float128 on PowerPC.
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+libgcc/
+
+ * config/rs6000/quad-float128.h (TF): Delete definition.
+ (TFtype): Define to be _Float128.
+ (TCtype): Change to be _Complex _Float128.
+ * libgcc2.h (TFtype): Allow MD code to override definition.
+ (TCtype): Likewise.
+ * soft-fp/quad.h (TFtype): Likewise.
+
+==================== Dmf004-orig branch, patch #3.
+
+Update float 128-bit conversions, PR target/107299.
+
+This patch fixes two tests that are still failing when long double is IEEE
+128-bit after the previous 2 patches for PR target/107299 have been applied.
+The tests are:
+
+ gcc.target/powerpc/convert-fp-128.c
+ gcc.target/powerpc/pr85657-3.c
+
+This patch is a rewrite of the patch submitted on August 18th:
+
+| https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599988.html
+
+This patch reworks the conversions between 128-bit binary floating point types.
+Previously, we would call rs6000_expand_float128_convert to do all conversions.
+Now, we only define the conversions between the same representation that turn
+into a NOP. The appropriate extend or truncate insn is generated, and after
+register allocation, it is converted to a move.
+
+This patch also fixes two places where we want to override the external name
+for the conversion function, and the wrong optab was used. Previously,
+rs6000_expand_float128_convert would handle the move or generate the call as
+needed. Now, it lets the machine independent code generate the call. But if
+we use the machine independent code to generate the call, we need to update the
+name for two optabs where a truncate would be used in terms of converting
+between the modes. This patch updates those two optabs.
+
+I tested this patch on:
+
+ 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+ 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+ 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm
+ 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm
+
+In the past I have also tested this exact patch on the following systems:
+
+ 1) LE Power10 using --with-cpu=power9 --with-long-double-format=ibm
+ 2) LE Power10 using --with-cpu=power8 --with-long-double-format=ibm
+ 3) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+
+There were no regressions in the bootstrap process or running the tests (after
+applying all 3 patches for PR target/107299). Can I check this patch into the
+trunk?
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+gcc/
+
+ PR target/107299
+ * config/rs6000/rs6000.cc (init_float128_ieee): Use the correct
+ float_extend or float_truncate optab based on how the machine converts
+ between IEEE 128-bit and IBM 128-bit.
+ * config/rs6000/rs6000.md (IFKF): Delete.
+ (IFKF_reg): Delete.
+ (extendiftf2): Rewrite to be a move if IFmode and TFmode are both IBM
+ 128-bit. Do not run if TFmode is IEEE 128-bit.
+ (extendifkf2): Delete.
+ (extendtfkf2): Delete.
+ (extendtfif2): Delete.
+ (trunciftf2): Delete.
+ (truncifkf2): Delete.
+ (trunckftf2): Delete.
+ (extendkftf2): Implement conversion of IEEE 128-bit types as a move.
+ (trunctfif2): Delete.
+ (trunctfkf2): Implement conversion of IEEE 128-bit types as a move.
+ (extend<mode>tf2_internal): Delete.
+ (extendtf<mode>2_internal): Delete.
+
+==================== Dmf004-orig branch, patch #2.
+
+Make __float128 use the _Float128 type, PR target/107299.
+
+This patch fixes the issue that GCC cannot build when the default long double
+is IEEE 128-bit. It fails in building libgcc, specifically when it is trying
+to buld the __mulkc3 function in libgcc. It is failing in gimple-range-fold.cc
+during the evrp pass. Ultimately it is failing because the code declared the
+type to use TFmode but it used F128 functions (i.e. KFmode).
+
+ typedef float TFtype __attribute__((mode (TF)));
+ typedef __complex float TCtype __attribute__((mode (TC)));
+
+ TCtype
+ __mulkc3_sw (TFtype a, TFtype b, TFtype c, TFtype d)
+ {
+ TFtype ac, bd, ad, bc, x, y;
+ TCtype res;
+
+ ac = a * c;
+ bd = b * d;
+ ad = a * d;
+ bc = b * c;
+
+ x = ac - bd;
+ y = ad + bc;
+
+ if (__builtin_isnan (x) && __builtin_isnan (y))
+ {
+ _Bool recalc = 0;
+ if (__builtin_isinf (a) || __builtin_isinf (b))
+ {
+
+ a = __builtin_copysignf128 (__builtin_isinf (a) ? 1 : 0, a);
+ b = __builtin_copysignf128 (__builtin_isinf (b) ? 1 : 0, b);
+ if (__builtin_isnan (c))
+ c = __builtin_copysignf128 (0, c);
+ if (__builtin_isnan (d))
+ d = __builtin_copysignf128 (0, d);
+ recalc = 1;
+ }
+ if (__builtin_isinf (c) || __builtin_isinf (d))
+ {
+
+ c = __builtin_copysignf128 (__builtin_isinf (c) ? 1 : 0, c);
+ d = __builtin_copysignf128 (__builtin_isinf (d) ? 1 : 0, d);
+ if (__builtin_isnan (a))
+ a = __builtin_copysignf128 (0, a);
+ if (__builtin_isnan (b))
+ b = __builtin_copysignf128 (0, b);
+ recalc = 1;
+ }
+ if (!recalc
+ && (__builtin_isinf (ac) || __builtin_isinf (bd)
+ || __builtin_isinf (ad) || __builtin_isinf (bc)))
+ {
+
+ if (__builtin_isnan (a))
+ a = __builtin_copysignf128 (0, a);
+ if (__builtin_isnan (b))
+ b = __builtin_copysignf128 (0, b);
+ if (__builtin_isnan (c))
+ c = __builtin_copysignf128 (0, c);
+ if (__builtin_isnan (d))
+ d = __builtin_copysignf128 (0, d);
+ recalc = 1;
+ }
+ if (recalc)
+ {
+ x = __builtin_inff128 () * (a * c - b * d);
+ y = __builtin_inff128 () * (a * d + b * c);
+ }
+ }
+
+ __real__ res = x;
+ __imag__ res = y;
+ return res;
+ }
+
+Currently GCC uses the long double type node for __float128 if long double is
+IEEE 128-bit. It did not use the node for _Float128.
+
+Originally this was noticed if you call the nansq function to make a signaling
+NaN (nansq is mapped to nansf128). Because the type node for _Float128 is
+different from __float128, the machine independent code converts signaling NaNs
+to quiet NaNs if the types are not compatible. The following tests used to
+fail when run on a system where long double is IEEE 128-bit:
+
+ gcc.dg/torture/float128-nan.c
+ gcc.target/powerpc/nan128-1.c
+
+This patch makes both __float128 and _Float128 use the same type node.
+
+One side effect of not using the long double type node for __float128 is that we
+must only use KFmode for _Float128/__float128. The libstdc++ library won't
+build if we use TFmode for _Float128 and __float128 when long double is IEEE
+128-bit.
+
+Another minor side effect is that the f128 round to odd fused multiply-add
+function will not merge negatition with the FMA operation when the type is long
+double. If the type is __float128 or _Float128, then it will continue to do the
+optimization. The round to odd functions are defined in terms of __float128
+arguments. For example:
+
+ long double
+ do_fms (long double a, long double b, long double c)
+ {
+ return __builtin_fmaf128_round_to_odd (a, b, -c);
+ }
+
+will generate (assuming -mabi=ieeelongdouble):
+
+ xsnegqp 4,4
+ xsmaddqpo 4,2,3
+ xxlor 34,36,36
+
+while:
+
+ __float128
+ do_fms (__float128 a, __float128 b, __float128 c)
+ {
+ return __builtin_fmaf128_round_to_odd (a, b, -c);
+ }
+
+will generate:
+
+ xsmsubqpo 4,2,3
+ xxlor 34,36,36
+
+I tested all 3 patchs for PR target/107299 on:
+
+ 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+ 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+ 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm
+ 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm
+
+Once all 3 patches have been applied, we can once again build GCC when long
+double is IEEE 128-bit. There were no other regressions with these patches.
+Can I check these patches into the trunk?
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+gcc/
+
+ PR target/107299
+ * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Always use the
+ _Float128 type for __float128.
+ (rs6000_expand_builtin): Only change a KFmode built-in to TFmode, if the
+ built-in passes or returns TFmode. If the predicate failed because the
+ modes were different, use convert_move to load up the value instead of
+ copy_to_mode_reg.
+ * config/rs6000/rs6000.cc (rs6000_translate_mode_attribute): Don't
+ translate IEEE 128-bit floating point modes to explicit IEEE 128-bit
+ modes (KFmode or KCmode), even if long double is IEEE 128-bit.
+ (rs6000_libgcc_floating_mode_supported_p): Support KFmode all of the
+ time if we support IEEE 128-bit floating point.
+ (rs6000_floatn_mode): _Float128 and _Float128x always uses KFmode.
+
+gcc/testsuite/
+
+ PR target/107299
+ * gcc.target/powerpc/float128-hw12.c: New test.
+ * gcc.target/powerpc/float128-hw13.c: Likewise.
+ * gcc.target/powerpc/float128-hw4.c: Update insns.
+
+==================== Dmf004-orig branch, patch #1.
+
+Rework 128-bit complex multiply and divide.
+
+This function reworks how the complex multiply and divide built-in functions are
+done. Previously we created built-in declarations for doing long double complex
+multiply and divide when long double is IEEE 128-bit. The old code also did not
+support __ibm128 complex multiply and divide if long double is IEEE 128-bit.
+
+In terms of history, I wrote the original code just as I was starting to test
+GCC on systems where IEEE 128-bit long double was the default. At the time, we
+had not yet started mangling the built-in function names as a way to bridge
+going from a system with 128-bit IBM long double to 128-bin IEEE long double.
+
+The original code depends on there only being two 128-bit types invovled. With
+the next patch in this series, this assumption will no longer be true. When
+long double is IEEE 128-bit, there will be 2 IEEE 128-bit types (one for the
+explicit __float128/_Float128 type and one for long double).
+
+The problem is we cannot create two separate built-in functions that resolve to
+the same name. This is a requirement of add_builtin_function and the C front
+end. That means for the 3 possible modes (IFmode, KFmode, and TFmode), you can
+only use 2 of them.
+
+This code does not create the built-in declaration with the changed name.
+Instead, it uses the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the name
+before it is written out to the assembler file like it now does for all of the
+other long double built-in functions.
+
+We need to disable using this mapping when we are building libgcc, specifically
+when it is building the floating point 128-bit multiply and divide functions.
+The flag that is used when libgcc is built (-fbuilding-libcc) is only available
+in the C/C++ front ends. We need to remember that we are building libgcc in the
+rs6000-c.cc support to be able to use this later to decided whether to mangle
+the decl assembler name or not.
+
+When I wrote these patches, I discovered that __ibm128 complex multiply and
+divide had originally not been supported if long double is IEEE 128-bit as it
+would generate calls to __mulic3 and __divic3. I added tests in the testsuite
+to verify that the correct name (i.e. __multc3 and __divtc3) is used in this
+case.
+
+I tested all 3 patchs for PR target/107299 on:
+
+ 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee
+ 2) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm
+ 3) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm
+ 4) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm
+
+Once all 3 patches have been applied, we can once again build GCC when long
+double is IEEE 128-bit. There were no other regressions with these patches.
+Can I check these patches into the trunk?
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+gcc/
+
+ PR target/107299
+ * config/rs6000/rs6000-c.cc (rs6000_cpu_cpp_builtins): Set
+ building_libgcc.
+ * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
+ (init_float128_ieee): Delete code to switch complex multiply and divide
+ for long double.
+ (complex_multiply_builtin_code): New helper function.
+ (complex_divide_builtin_code): Likewise.
+ (rs6000_mangle_decl_assembler_name): Add support for mangling the name
+ of complex 128-bit multiply and divide built-in functions.
+ * config/rs6000/rs6000.opt (building_libgcc): New target variable.
+
+gcc/testsuite/
+
+ PR target/107299
+ * gcc.target/powerpc/divic3-1.c: New test.
+ * gcc.target/powerpc/divic3-2.c: Likewise.
+ * gcc.target/powerpc/mulic3-1.c: Likewise.
+ * gcc.target/powerpc/mulic3-2.c: Likewise.
+
+==================== Dmf004-orig branch, head.
+
+2022-11-09 Michael Meissner <meissner@linux.ibm.com>
+
+ Clone branch
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-11-17 21:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-17 21:50 [gcc(refs/users/meissner/heads/dmf004-orig)] Update ChangeLog.meissner Michael Meissner
-- strict thread matches above, loose matches on Subject: below --
2022-11-09 5:35 Michael Meissner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).