[2/2] Rework 128-bit complex multiply and divide.
Commit Message
This patch 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.
This patch was originally posted on December 13th, 2022:
| Date: Tue, 13 Dec 2022 01:21:06 -0500
| Subject: [PATCH V2] Rework 128-bit complex multiply and divide, PR target/107299
| Message-ID: <Y5gZ0o1nzCq9MmR9@toto.the-meissners.org>
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.
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 had previously sent this patch out on November 1st. Compared to that version,
this version no longer disables the special mapping when you are building
libgcc, as it turns out we don't need it.
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?
Note, it is Friday February 3rd, 2023. I will be on vacation Tuesday February
7th through February 14th.
2023-02-02 Michael Meissner <meissner@linux.ibm.com>
gcc/
PR target/107299
* 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/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.
---
gcc/config/rs6000/rs6000.cc | 109 +++++++++++---------
gcc/testsuite/gcc.target/powerpc/divic3-1.c | 18 ++++
gcc/testsuite/gcc.target/powerpc/divic3-2.c | 17 +++
gcc/testsuite/gcc.target/powerpc/mulic3-1.c | 18 ++++
gcc/testsuite/gcc.target/powerpc/mulic3-2.c | 17 +++
5 files changed, 132 insertions(+), 47 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/divic3-1.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/divic3-2.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/mulic3-1.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/mulic3-2.c
Comments
Hi Mike,
on 2023/2/3 13:53, Michael Meissner wrote:
> This patch 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.
>
> This patch was originally posted on December 13th, 2022:
>
> | Date: Tue, 13 Dec 2022 01:21:06 -0500
> | Subject: [PATCH V2] Rework 128-bit complex multiply and divide, PR target/107299
> | Message-ID: <Y5gZ0o1nzCq9MmR9@toto.the-meissners.org>
>
> 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.
>
> 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 had previously sent this patch out on November 1st. Compared to that version,
> this version no longer disables the special mapping when you are building
> libgcc, as it turns out we don't need it.
>
> 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?
These two above paragraphs look a bit out of date (two patches now). :)
IIUC this patch actually fixes a latent issue, so it is independent of the one
fixing the bootstrapping issue, right? This updated version of patch looks
good to me, but I'd leave the approval to Segher/David. Thanks!
BR,
Kewen
On Wed, Feb 22, 2023 at 06:13:07PM +0800, Kewen.Lin wrote:
> These two above paragraphs look a bit out of date (two patches now). :)
Thanks.
> IIUC this patch actually fixes a latent issue, so it is independent of the one
> fixing the bootstrapping issue, right? This updated version of patch looks
> good to me, but I'd leave the approval to Segher/David. Thanks!
Yes, I've been waiting for Segher or David's approval for this for awhile.
The history is it is indeed a latent issue (not supporting __ibm128 complex
multiply and divide when long double is IEEE 128-bit). However, at the time I
wrote it, the other changes had broken the complex multiply and divide, and I
wrote this patch as part of the series. I separated the patch from the other 2
to make it simpler to go in. But it seems to be in limbo.
This patch is second in importance after the first patch in the series. It is
needed to allow complex IBM 128-bit multiply/divide when long double is IEEE
128-bit.
| Date: Fri, 3 Feb 2023 00:53:05 -0500
| From: Michael Meissner <meissner@linux.ibm.com>
| Subject: [PATCH 2/2] Rework 128-bit complex multiply and divide.
| Message-ID: <Y9yhQQdUaM+z6IYD@toto.the-meissners.org>
Hi!
On Fri, Feb 03, 2023 at 12:53:05AM -0500, Michael Meissner wrote:
> This patch reworks how the complex multiply and divide built-in functions are
> done.
> I tested all 3 patchs for PR target/107299 on:
Is this part of the proposed commit message? As Ke Wen pointed out, it
is wrong. Most of your mail does not belong in a commit message at all,
but some probably does? Please do this clearer with future patches.
> * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
> (init_float128_ieee): Delete code to switch complex multiply and divide
> for long double.
I like this kind of patch :-)
> +/* 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)
> +{
> + return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode
> + - MIN_MODE_COMPLEX_FLOAT);
> +}
There should be an assert that the mode is as expected
gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT));
or such.
Using more temporaries should make this simpler as well, obviate the
need for explicit casts, and make everything fit on short lines.
> +static inline built_in_function
> +complex_divide_builtin_code (machine_mode mode)
> +{
> + return (built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + mode
> + - MIN_MODE_COMPLEX_FLOAT);
> +}
Ditto ofc.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile { target { powerpc*-*-* } } } */
Leave the target clause out.
> +/* { dg-require-effective-target powerpc_p8vector_ok } */
> +/* { dg-require-effective-target longdouble128 } */
> +/* { dg-require-effective-target ppc_float128_sw } */
> +/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */
It would be nice if you did not try to add -mpower8-vector in more
testcases :-(
Is -Wno-psabi needed here? What is the error you get without it / on
which configurations? Cargo-culting hiding the warnings makes you see
fewer warnings, but that is the opposite of a good idea.
> +/* { dg-final { scan-assembler "bl __divtc3" } } */
This name depends on what object format and ABI is in use (some have an
extra leading underscore, or a dot, or whatever).
Segher
On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Feb 03, 2023 at 12:53:05AM -0500, Michael Meissner wrote:
> > This patch reworks how the complex multiply and divide built-in functions are
> > done.
>
> > I tested all 3 patchs for PR target/107299 on:
>
> Is this part of the proposed commit message? As Ke Wen pointed out, it
> is wrong. Most of your mail does not belong in a commit message at all,
> but some probably does? Please do this clearer with future patches.
>
> > * config/rs6000/rs6000.cc (create_complex_muldiv): Delete.
> > (init_float128_ieee): Delete code to switch complex multiply and divide
> > for long double.
>
> I like this kind of patch :-)
>
> > +/* 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)
> > +{
> > + return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode
> > + - MIN_MODE_COMPLEX_FLOAT);
> > +}
>
> There should be an assert that the mode is as expected
> gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT));
> or such.
Ok.
> Using more temporaries should make this simpler as well, obviate the
> need for explicit casts, and make everything fit on short lines.
>
> > +static inline built_in_function
> > +complex_divide_builtin_code (machine_mode mode)
> > +{
> > + return (built_in_function) (BUILT_IN_COMPLEX_DIV_MIN + mode
> > + - MIN_MODE_COMPLEX_FLOAT);
> > +}
>
> Ditto ofc.
>
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c
> > @@ -0,0 +1,18 @@
> > +/* { dg-do compile { target { powerpc*-*-* } } } */
>
> Leave the target clause out.
Ok.
> > +/* { dg-require-effective-target powerpc_p8vector_ok } */
> > +/* { dg-require-effective-target longdouble128 } */
> > +/* { dg-require-effective-target ppc_float128_sw } */
> > +/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */
>
> It would be nice if you did not try to add -mpower8-vector in more
> testcases :-(
Yep.
> Is -Wno-psabi needed here? What is the error you get without it / on
> which configurations? Cargo-culting hiding the warnings makes you see
> fewer warnings, but that is the opposite of a good idea.
>
> > +/* { dg-final { scan-assembler "bl __divtc3" } } */
>
> This name depends on what object format and ABI is in use (some have an
> extra leading underscore, or a dot, or whatever).
Yes it is needed if GCC is configured against an older GLIBC before the full
IEEE 128-bit support was added. For example, on my big endian test system, you
get warnings if you switch the floating point format. I would imagine it would
also fail on little endian system with older libraries.
On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> > +complex_multiply_builtin_code (machine_mode mode)
> > +{
> > + return (built_in_function) (BUILT_IN_COMPLEX_MUL_MIN + mode
> > + - MIN_MODE_COMPLEX_FLOAT);
> > +}
>
> There should be an assert that the mode is as expected
> gcc_assert (IN_RANGE (mode, MIN_MODE_COMPLEX_FLOAT, MAX_MODE_COMPLEX_FLOAT));
> or such.
>
> Using more temporaries should make this simpler as well, obviate the
> need for explicit casts, and make everything fit on short lines.
While I can use a temporary to shorten the line, I can't eliminate the case, or
I'll get a warning about implicit conversion from int to the enum
built_in_function. Here is what I will use:
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));
int func = BUILT_IN_COMPLEX_MUL_MIN + mode - MIN_MODE_COMPLEX_FLOAT;
return (built_in_function) func;
}
On Thu, Mar 09, 2023 at 11:11:34AM -0500, Michael Meissner wrote:
> On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> > > +/* { dg-final { scan-assembler "bl __divtc3" } } */
> >
> > This name depends on what object format and ABI is in use (some have an
> > extra leading underscore, or a dot, or whatever).
>
> Yes it is needed if GCC is configured against an older GLIBC before the full
> IEEE 128-bit support was added. For example, on my big endian test system, you
> get warnings if you switch the floating point format. I would imagine it would
> also fail on little endian system with older libraries.
The regexp is not good enough, that is all. Maybe
{bl .?__divtc3}
or similar? We have many examples in the tests already.
Segher
On Thu, Mar 09, 2023 at 04:16:21PM -0600, Segher Boessenkool wrote:
> On Thu, Mar 09, 2023 at 11:11:34AM -0500, Michael Meissner wrote:
> > On Fri, Mar 03, 2023 at 03:35:44PM -0600, Segher Boessenkool wrote:
> > > > +/* { dg-final { scan-assembler "bl __divtc3" } } */
> > >
> > > This name depends on what object format and ABI is in use (some have an
> > > extra leading underscore, or a dot, or whatever).
> >
> > Yes it is needed if GCC is configured against an older GLIBC before the full
> > IEEE 128-bit support was added. For example, on my big endian test system, you
> > get warnings if you switch the floating point format. I would imagine it would
> > also fail on little endian system with older libraries.
>
> The regexp is not good enough, that is all. Maybe
> {bl .?__divtc3}
> or similar? We have many examples in the tests already.
I forgot the mention the regexp. I think just doing:
/* { dg-final { scan-assembler "__multc3" } } */
is sufficient.
@@ -11151,26 +11151,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
@@ -11182,32 +11162,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");
@@ -28225,6 +28179,25 @@ rs6000_starting_frame_offset (void)
return RS6000_STARTING_FRAME_OFFSET;
}
+/* 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)
+{
+ 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)
+{
+ 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
@@ -28243,11 +28216,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)
new file mode 100644
@@ -0,0 +1,18 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target longdouble128 } */
+/* { dg-require-effective-target ppc_float128_sw } */
+/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */
+
+/* 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" } } */
new file mode 100644
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target longdouble128 } */
+/* { dg-options "-O2 -mpower8-vector -mabi=ibmlongdouble -Wno-psabi" } */
+
+/* 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" } } */
new file mode 100644
@@ -0,0 +1,18 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target longdouble128 } */
+/* { dg-require-effective-target ppc_float128_sw } */
+/* { dg-options "-O2 -mpower8-vector -mabi=ieeelongdouble -Wno-psabi" } */
+
+/* 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 "bl __multc3" } } */
new file mode 100644
@@ -0,0 +1,17 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-require-effective-target longdouble128 } */
+/* { dg-options "-O2 -mpower8-vector -mabi=ibmlongdouble -Wno-psabi" } */
+
+/* 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 "bl __multc3" } } */