public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Michael Meissner <meissner@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc(refs/users/meissner/heads/work102)] Update ChangeLog.meissner.
Date: Thu,  8 Dec 2022 20:57:00 +0000 (GMT)	[thread overview]
Message-ID: <20221208205700.3248C39726BD@sourceware.org> (raw)

https://gcc.gnu.org/g:30e0358e36895fc8efeac6702447ada6c3506e94

commit 30e0358e36895fc8efeac6702447ada6c3506e94
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Thu Dec 8 15:56:38 2022 -0500

    Update ChangeLog.meissner.
    
    2022-12-08   Michael Meissner  <meissner@linux.ibm.com>
    
    gcc/
    
            * ChangeLog.meissner: Update.

Diff:
---
 gcc/ChangeLog.meissner | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 79 insertions(+)

diff --git a/gcc/ChangeLog.meissner b/gcc/ChangeLog.meissner
index f618ba3f577..f7cab93182b 100644
--- a/gcc/ChangeLog.meissner
+++ b/gcc/ChangeLog.meissner
@@ -1,3 +1,82 @@
+==================== work102, 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-01   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.
+
+==================== work102, initial branch.
+
 2022-12-08   Michael Meissner  <meissner@linux.ibm.com>
 
 	Clone branch

             reply	other threads:[~2022-12-08 20:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-08 20:57 Michael Meissner [this message]
2022-12-08 21:48 Michael Meissner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221208205700.3248C39726BD@sourceware.org \
    --to=meissner@gcc.gnu.org \
    --cc=gcc-cvs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).