From patchwork Thu Aug 18 21:46:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Meissner X-Patchwork-Id: 612 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:6a10:38f:b0:2d5:3c95:9e21 with SMTP id 15csp542822pxh; Thu, 18 Aug 2022 14:47:47 -0700 (PDT) X-Google-Smtp-Source: AA6agR4sbUNot4WQxNoR7mvt0aDNMD+iA7yF1zFne8hzV0X0Rjl1kKxJsSyGjY1ZVKuRZwrzHUlh X-Received: by 2002:a05:6402:50cb:b0:440:8bac:1e02 with SMTP id h11-20020a05640250cb00b004408bac1e02mr3843742edb.336.1660859267255; Thu, 18 Aug 2022 14:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660859267; cv=none; d=google.com; s=arc-20160816; b=Yy71vLS8FJV5Y+8CVnYJExovBataAF2IcvcIhn9ZI+GcEymwWGUtD605lvs3jLJTAK g8QEO6yFaW+fd29/F5bgGJMYMUvHuTBgWcqtkB1TqosBHOrY5T1bM6WbtxK90P4f7JeO v5lN6Ila6G+zIGsg6ktk8qQTgwJx6kY70pB4vk7xAkuH+newkLJSVOTTvI5sX/G9Vpnl pTMpLYc1HM0c0/6jY1BA+IXEPWFmZ3wJJiKLu6qoJpGHqT2N34C61byb09UwkbpOqkpq udYE2MRU+p/+7TB0JvjJ2ks5r58AH7MVowgZGKnDud9EAcSbwRSC7WdGzmnLnPXA1gFU BaLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:mail-followup-to:message-id :subject:to:date:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=NZ7id5WbCEYO/aMXUZ6xfuiZQkV0TwV41fJCBD//frc=; b=G4Jgx7mr7udgUJbUUdDm/BLffMxuO1Fc0x63ZGgMYTFxWgzcMbBT1S5cT8wCnNS8bm lcE2i6d6mDxoH1Jh7WjUuJVCx4/ZUjk1vqdIcoliFNRJt4C6aqbfVQJFkbACEcgNXWgR NSCvMZTaBolp1T4x2FmO5n6hTEWZLC13xYyUwVlEpZEMxSYE1a4ZzTZgVJFIXe08R63c /JvHgzElCezBgh5JyvV7temv7+r5skSqRq6Mvy2REF1dHh+QjfsMubH8H72pLhZtT/1l 0wTDP5yAmfrB2SbBAgyOasx6vdtjVmmTm7Nhm68J7J16+3JYzVFtPHndOzs2sHmPfsqT y6LQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=KksKXicd; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [2620:52:3:1:0:246e:9693:128c]) by mx.google.com with ESMTPS id nd22-20020a170907629600b0073c5d9b3440si818754ejc.781.2022.08.18.14.47.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Aug 2022 14:47:47 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) client-ip=2620:52:3:1:0:246e:9693:128c; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=KksKXicd; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 2620:52:3:1:0:246e:9693:128c as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C78823858C83 for ; Thu, 18 Aug 2022 21:47:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C78823858C83 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1660859265; bh=NZ7id5WbCEYO/aMXUZ6xfuiZQkV0TwV41fJCBD//frc=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=KksKXicd+DM7NLFr4JyKSuTM6IgHMGl5dPmqjZiN4S5uh2Yqb3j+0fZWVDKFiSgmG BZZpDRIaguK/uBs+ZZO68/T1t0G74Aw31cc5J1VqpiCMRvKv/rs6GRiPbmSrhFjz1X +uUVCkGCX1O5H+DAR9DpryJ5o12Tq9FbAmy4HC4s= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id A49BE3858D28 for ; Thu, 18 Aug 2022 21:46:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A49BE3858D28 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 27ILfsne027589; Thu, 18 Aug 2022 21:46:57 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1wjnr3nk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 21:46:57 +0000 Received: from m0098404.ppops.net (m0098404.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 27ILhTrA004810; Thu, 18 Aug 2022 21:46:56 GMT Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3j1wjnr3n8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 21:46:56 +0000 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 27ILM2SY015847; Thu, 18 Aug 2022 21:46:55 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma02wdc.us.ibm.com with ESMTP id 3hx3ka96br-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Aug 2022 21:46:54 +0000 Received: from b03ledav006.gho.boulder.ibm.com (b03ledav006.gho.boulder.ibm.com [9.17.130.237]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 27ILksiJ51904848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 18 Aug 2022 21:46:54 GMT Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E251BC6057; Thu, 18 Aug 2022 21:46:53 +0000 (GMT) Received: from b03ledav006.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 30593C6059; Thu, 18 Aug 2022 21:46:53 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.225.181]) by b03ledav006.gho.boulder.ibm.com (Postfix) with ESMTPS; Thu, 18 Aug 2022 21:46:52 +0000 (GMT) Date: Thu, 18 Aug 2022 17:46:51 -0400 To: gcc-patches@gcc.gnu.org, Michael Meissner , Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt Subject: [PATCH] Rework 128-bit complex multiply and divide. Message-ID: Mail-Followup-To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt MIME-Version: 1.0 Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Q1MSP7-YD_pwDpFkdhs_YO8KEHOes4EH X-Proofpoint-GUID: x8SKmtFfGcIhDcJNnHD6Nl-LX26u0ceT X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-08-18_16,2022-08-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 mlxscore=0 malwarescore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 phishscore=0 impostorscore=0 clxscore=1015 mlxlogscore=999 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2207270000 definitions=main-2208180077 X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_MANYTO, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Michael Meissner via Gcc-patches From: Michael Meissner Reply-To: Michael Meissner Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1741537166919151002?= X-GMAIL-MSGID: =?utf-8?q?1741537166919151002?= 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 some of the changes that I plan on making, this assumption will no longer be true in the future. 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, which is creating the 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 have tested this patch on the following systems: 1) LE Power10 using --with-cpu=power10 --with-long-double-format=ieee 2) LE Power10 using --with-cpu=power9 --with-long-double-format=ibm 3) LE Power10 using --with-cpu=power8 --with-long-double-format=ibm 4) LE Power10 using --with-cpu=power10 --with-long-double-format=ibm 5) LE Power9 using --with-cpu=power9 --with-long-double-format=ibm 6) BE Power8 using --with-cpu=power8 --with-long-double-format=ibm 7) BE Power8 using --with-cpu=power5 --with-long-double-format=ibm There were no regressions in the build or in the tests. Can I check this patch into the trunk? Note this patch needs the first patch in the __ibm128 patches that I posted on Thursday August 18th for the TARGET_IBM128 declaration. If those patches are rejected, it would be fairly simple to change the one use of TARGET_IBM128. Did we want to backport this to earlier GCC releases? 2022-08-17 Michael Meissner gcc/ * 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/ * 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-c.cc | 8 ++ gcc/config/rs6000/rs6000.cc | 110 +++++++++++--------- gcc/config/rs6000/rs6000.opt | 4 + 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 +++ 7 files changed, 145 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 diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc index 4d051b90658..11de8389fd6 100644 --- a/gcc/config/rs6000/rs6000-c.cc +++ b/gcc/config/rs6000/rs6000-c.cc @@ -780,6 +780,14 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfile) || DEFAULT_ABI == ABI_ELFv2 || (DEFAULT_ABI == ABI_AIX && !rs6000_compat_align_parm)) builtin_define ("__STRUCT_PARM_ALIGN__=16"); + + /* Store whether or not we are building libgcc. This is needed to disable + generating the alternate names for 128-bit complex multiply and divide. + We need to disable generating __multc3, __divtc3, __mulkc3, and __divkc3 + when we are building those functions in libgcc. The variable + flag_building_libgcc is only available for the C family of front-ends. + We set this variable here to disable generating the alternate names. */ + building_libgcc = flag_building_libgcc; } diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index 046c538c748..0bc87d2d5d8 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -10966,26 +10966,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_ for the names, so @@ -10997,32 +10977,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"); @@ -27971,6 +27925,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 l to f128 if the default long double type is @@ -27989,11 +27962,54 @@ 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 || TARGET_IBM128) + && !building_libgcc + && 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/config/rs6000/rs6000.opt b/gcc/config/rs6000/rs6000.opt index b227bf96888..1299d47e5b2 100644 --- a/gcc/config/rs6000/rs6000.opt +++ b/gcc/config/rs6000/rs6000.opt @@ -100,6 +100,10 @@ unsigned int rs6000_recip_control TargetVariable unsigned int rs6000_debug +;; Whether we are building libgcc or not. +TargetVariable +bool building_libgcc = false + ;; Whether to enable the -mfloat128 stuff without necessarily enabling the ;; __float128 keyword. TargetSave 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..1cc6b1be904 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/divic3-1.c @@ -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" } } */ 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..8ff342e0116 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/divic3-2.c @@ -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" } } */ 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..4cd773c4b06 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/mulic3-1.c @@ -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" } } */ 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..36fe8bc3061 --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/mulic3-2.c @@ -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" } } */