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/dmf010)] Rework 128-bit complex multiply and divide. Date: Thu, 9 Mar 2023 05:05:42 +0000 (GMT) [thread overview] Message-ID: <20230309050542.DA8353858D37@sourceware.org> (raw) https://gcc.gnu.org/g:4bfcc0ec22472ec742843401c7bafb90a91ac2cc commit 4bfcc0ec22472ec742843401c7bafb90a91ac2cc Author: Michael Meissner <meissner@linux.ibm.com> Date: Thu Mar 9 00:05:23 2023 -0500 Rework 128-bit complex multiply and divide. This patch reworks how the complex multiply and divide built-in functions are done. Previously GCC created built-in declarations for doing long double complex multiply and divide when long double is IEEE 128-bit. However, it did not support __ibm128 complex multiply and divide if long double is IEEE 128-bit. 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. 2023-03-08 Michael Meissner <meissner@linux.ibm.com> gcc/ PR target/109067 * 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. gcc/testsuite/ PR target/109067 * 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. Diff: --- gcc/config/rs6000/rs6000.cc | 111 ++++++++++++++++------------ gcc/testsuite/gcc.target/powerpc/divic3-1.c | 21 ++++++ gcc/testsuite/gcc.target/powerpc/divic3-2.c | 25 +++++++ gcc/testsuite/gcc.target/powerpc/mulic3-1.c | 21 ++++++ gcc/testsuite/gcc.target/powerpc/mulic3-2.c | 25 +++++++ 5 files changed, 156 insertions(+), 47 deletions(-) diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index 8e0b0d022db..b1b35b4bb77 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -11154,26 +11154,6 @@ init_float128_ibm (machine_mode mode) } } -/* Create a decl for either complex long double multiply or complex long double - divide when long double is IEEE 128-bit floating point. We can't use - __multc3 and __divtc3 because the original long double using IBM extended - double used those names. The complex multiply/divide functions are encoded - as builtin functions with a complex result and 4 scalar inputs. */ - -static void -create_complex_muldiv (const char *name, built_in_function fncode, tree fntype) -{ - tree fndecl = add_builtin_function (name, fntype, fncode, BUILT_IN_NORMAL, - name, NULL_TREE); - - set_builtin_decl (fncode, fndecl, true); - - if (TARGET_DEBUG_BUILTIN) - fprintf (stderr, "create complex %s, fncode: %d\n", name, (int) fncode); - - return; -} - /* Set up IEEE 128-bit floating point routines. Use different names if the arguments can be passed in a vector register. The historical PowerPC implementation of IEEE 128-bit floating point used _q_<op> for the names, so @@ -11185,32 +11165,6 @@ init_float128_ieee (machine_mode mode) { if (FLOAT128_VECTOR_P (mode)) { - static bool complex_muldiv_init_p = false; - - /* Set up to call __mulkc3 and __divkc3 under -mabi=ieeelongdouble. If - we have clone or target attributes, this will be called a second - time. We want to create the built-in function only once. */ - if (mode == TFmode && TARGET_IEEEQUAD && !complex_muldiv_init_p) - { - complex_muldiv_init_p = true; - built_in_function fncode_mul = - (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + TCmode - - MIN_MODE_COMPLEX_FLOAT); - built_in_function fncode_div = - (built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + TCmode - - MIN_MODE_COMPLEX_FLOAT); - - tree fntype = build_function_type_list (complex_long_double_type_node, - long_double_type_node, - long_double_type_node, - long_double_type_node, - long_double_type_node, - NULL_TREE); - - create_complex_muldiv ("__mulkc3", fncode_mul, fntype); - create_complex_muldiv ("__divkc3", fncode_div, fntype); - } - set_optab_libfunc (add_optab, mode, "__addkf3"); set_optab_libfunc (sub_optab, mode, "__subkf3"); set_optab_libfunc (neg_optab, mode, "__negkf2"); @@ -28228,6 +28182,27 @@ rs6000_starting_frame_offset (void) return RS6000_STARTING_FRAME_OFFSET; } \f +/* Internal function to return the built-in function id for the complex + multiply operation for a given mode. */ + +static inline built_in_function +complex_multiply_builtin_code (machine_mode mode) +{ + gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT)); + return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode + - MIN_MODE_COMPLEX_FLOAT); +} + +/* Internal function to return the built-in function id for the complex divide + operation for a given mode. */ + +static inline built_in_function +complex_divide_builtin_code (machine_mode mode) +{ + gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT)); + return (built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + mode + - MIN_MODE_COMPLEX_FLOAT); +} /* On 64-bit Linux and Freebsd systems, possibly switch the long double library function names from <foo>l to <foo>f128 if the default long double type is @@ -28246,11 +28221,53 @@ rs6000_starting_frame_offset (void) only do this transformation if the __float128 type is enabled. This prevents us from doing the transformation on older 32-bit ports that might have enabled using IEEE 128-bit floating point as the default long double - type. */ + type. + + We also use the TARGET_MANGLE_DECL_ASSEMBLER_NAME hook to change the + function names used for complex multiply and divide to the appropriate + names. */ static tree rs6000_mangle_decl_assembler_name (tree decl, tree id) { + /* Handle complex multiply/divide. For IEEE 128-bit, use __mulkc3 or + __divkc3 and for IBM 128-bit use __multc3 and __divtc3. */ + if (TARGET_FLOAT128_TYPE + && TREE_CODE (decl) == FUNCTION_DECL + && DECL_IS_UNDECLARED_BUILTIN (decl) + && DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL) + { + built_in_function id = DECL_FUNCTION_CODE (decl); + const char *newname = NULL; + + if (id == complex_multiply_builtin_code (KCmode)) + newname = "__mulkc3"; + + else if (id == complex_multiply_builtin_code (ICmode)) + newname = "__multc3"; + + else if (id == complex_multiply_builtin_code (TCmode)) + newname = (TARGET_IEEEQUAD) ? "__mulkc3" : "__multc3"; + + else if (id == complex_divide_builtin_code (KCmode)) + newname = "__divkc3"; + + else if (id == complex_divide_builtin_code (ICmode)) + newname = "__divtc3"; + + else if (id == complex_divide_builtin_code (TCmode)) + newname = (TARGET_IEEEQUAD) ? "__divkc3" : "__divtc3"; + + if (newname) + { + if (TARGET_DEBUG_BUILTIN) + fprintf (stderr, "Map complex mul/div => %s\n", newname); + + return get_identifier (newname); + } + } + + /* Map long double built-in functions if long double is IEEE 128-bit. */ if (TARGET_FLOAT128_TYPE && TARGET_IEEEQUAD && TARGET_LONG_DOUBLE_128 && TREE_CODE (decl) == FUNCTION_DECL && DECL_IS_UNDECLARED_BUILTIN (decl) diff --git a/gcc/testsuite/gcc.target/powerpc/divic3-1.c b/gcc/testsuite/gcc.target/powerpc/divic3-1.c new file mode 100644 index 00000000000..8bf188617aa --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c @@ -0,0 +1,21 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target ppc_float128_sw } */ +/* { dg-options "-O2 -mabi=ieeelongdouble" } */ + +/* When GCC is configured with an older library that does not support IEEE + 128-bit, it issues a warning if you change the long double type. We use + -Wno-psabi to silence this warning. Since this is a code generation test, + it does not matter if the library has full IEEE 128-bit support. */ + +/* Check that complex divide generates the right call for __ibm128 when long + double is IEEE 128-bit floating point. */ + +typedef _Complex long double c_ibm128_t __attribute__((mode(__IC__))); + +void +divide (c_ibm128_t *p, c_ibm128_t *q, c_ibm128_t *r) +{ + *p = *q / *r; +} + +/* { dg-final { scan-assembler "bl __divtc3" } } */ diff --git a/gcc/testsuite/gcc.target/powerpc/divic3-2.c b/gcc/testsuite/gcc.target/powerpc/divic3-2.c new file mode 100644 index 00000000000..f0efb76ec7d --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/divic3-2.c @@ -0,0 +1,25 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target ppc_float128_sw } */ +/* { dg-require-effective-target longdouble128 } */ +/* { dg-options "-O2 -mabi=ibmlongdouble" } */ + +/* When GCC is configured with an older library that does not support IEEE + 128-bit, it issues a warning if you change the long double type. We use + -Wno-psabi to silence this warning. Since this is a code generation test, + it does not matter if the library has full IEEE 128-bit support. + + We also need to require that the default long double is 128-bits, otherwise + the TC/TF modes might not be available. */ + +/* Check that complex divide generates the right call for __ibm128 when long + double is IBM 128-bit floating point. */ + +typedef _Complex long double c_ibm128_t __attribute__((mode(__TC__))); + +void +divide (c_ibm128_t *p, c_ibm128_t *q, c_ibm128_t *r) +{ + *p = *q / *r; +} + +/* { dg-final { scan-assembler "bl __divtc3" } } */ diff --git a/gcc/testsuite/gcc.target/powerpc/mulic3-1.c b/gcc/testsuite/gcc.target/powerpc/mulic3-1.c new file mode 100644 index 00000000000..ac23c3e3437 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/mulic3-1.c @@ -0,0 +1,21 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target ppc_float128_sw } */ +/* { dg-options "-O2 -mabi=ieeelongdouble" } */ + +/* When GCC is configured with an older library that does not support IEEE + 128-bit, it issues a warning if you change the long double type. We use + -Wno-psabi to silence this warning. Since this is a code generation test, + it does not matter if the library has full IEEE 128-bit support. */ + +/* Check that complex multiply generates the right call for __ibm128 when long + double is IEEE 128-bit floating point. */ + +typedef _Complex long double c_ibm128_t __attribute__((mode(__IC__))); + +void +multiply (c_ibm128_t *p, c_ibm128_t *q, c_ibm128_t *r) +{ + *p = *q * *r; +} + +/* { dg-final { scan-assembler "__multc3" } } */ diff --git a/gcc/testsuite/gcc.target/powerpc/mulic3-2.c b/gcc/testsuite/gcc.target/powerpc/mulic3-2.c new file mode 100644 index 00000000000..75355160596 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/mulic3-2.c @@ -0,0 +1,25 @@ +/* { dg-do compile } */ +/* { dg-require-effective-target ppc_float128_sw } */ +/* { dg-require-effective-target longdouble128 } */ +/* { dg-options "-O2 -mabi=ibmlongdouble" } */ + +/* When GCC is configured with an older library that does not support IEEE + 128-bit, it issues a warning if you change the long double type. We use + -Wno-psabi to silence this warning. Since this is a code generation test, + it does not matter if the library has full IEEE 128-bit support. + + We also need to require that the default long double is 128-bits, otherwise + the TC/TF modes might not be available. */ + +/* Check that complex multiply generates the right call for __ibm128 when long + double is IBM 128-bit floating point. */ + +typedef _Complex long double c_ibm128_t __attribute__((mode(__TC__))); + +void +multiply (c_ibm128_t *p, c_ibm128_t *q, c_ibm128_t *r) +{ + *p = *q * *r; +} + +/* { dg-final { scan-assembler "__multc3" } } */
next reply other threads:[~2023-03-09 5:05 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-09 5:05 Michael Meissner [this message] -- strict thread matches above, loose matches on Subject: below -- 2023-03-09 23:27 Michael Meissner 2023-03-09 16:54 Michael Meissner 2023-03-08 19:41 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=20230309050542.DA8353858D37@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: linkBe 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).