From patchwork Mon Jan 16 09:39:04 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kewen.Lin" X-Patchwork-Id: 63225 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AEBCA3858C66 for ; Mon, 16 Jan 2023 09:39:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AEBCA3858C66 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673861988; bh=nx7iTBDwFYc7g8q02DEMqhr04jrhqDsphxFqz3i8PLg=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=dqM1wupW1TEeBt58bCg8ivlr/YDLRL2TfPtJ2jHNhWXhE/v0FNx2ptrwyxNL6TK9F wUg4/GXoUPPGsv2xZ8B/IpG6lHv+0cX3I176m+bpb4pEo2MKzvKAHE0whRT4WFOGEb SqR/tw9Wr7qK0A5jmWGB2vo1yb4lAjdMZpgA9h1I= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 5726F3858D33 for ; Mon, 16 Jan 2023 09:39:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5726F3858D33 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30G8beWT005101; Mon, 16 Jan 2023 09:39:16 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3n48y5huy9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Jan 2023 09:39:16 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 30G9TnUP013325; Mon, 16 Jan 2023 09:39:16 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3n48y5huxr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Jan 2023 09:39:15 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 30G1qXla023688; Mon, 16 Jan 2023 09:39:14 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma03ams.nl.ibm.com (PPS) with ESMTPS id 3n3m16j71t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Jan 2023 09:39:14 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 30G9dAu424314416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 16 Jan 2023 09:39:10 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 81B7120049; Mon, 16 Jan 2023 09:39:10 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72AA520043; Mon, 16 Jan 2023 09:39:08 +0000 (GMT) Received: from [9.200.38.48] (unknown [9.200.38.48]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 16 Jan 2023 09:39:08 +0000 (GMT) Message-ID: <6305f0e5-d235-8916-6d42-7110cfede236@linux.ibm.com> Date: Mon, 16 Jan 2023 17:39:04 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: [PATCH/RFC] rs6000: Remove optimize_for_speed check for implicit TARGET_SAVE_TOC_INDIRECT [PR108184] Content-Language: en-US To: GCC Patches Cc: Segher Boessenkool , David Edelsohn , Peter Bergner , Michael Meissner References: In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: 3jk2PUycFMiL63GIoVEfwosSQ4SumgAI X-Proofpoint-ORIG-GUID: dyZChhDxnvQFxNFbn4oCFp_nSY-fA-lo X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-16_07,2023-01-13_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 suspectscore=0 malwarescore=0 phishscore=0 clxscore=1015 spamscore=0 mlxscore=0 mlxlogscore=503 lowpriorityscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2301160070 X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: "Kewen.Lin via Gcc-patches" From: "Kewen.Lin" Reply-To: "Kewen.Lin" Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi, Now we will check optimize_function_for_speed_p (cfun) for TARGET_SAVE_TOC_INDIRECT if it's implicitly enabled. But the effect of -msave-toc-indirect is actually to save the TOC in the prologue for indirect calls rather than inline, it's also good for optimize_function_for_size? So this patch is to remove the check of optimize_function_for_speed and make it work for both optimizing for size and speed. Bootstrapped and regtested on powerpc64-linux-gnu P8, powerpc64le-linux-gnu P{9,10} and powerpc-ibm-aix. Any thoughts? Thanks in advance! Kewen ----- gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_call_aix): Remove the check of optimize_function_for_speed_p for implicit SAVE_TOC_INDIRECT. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr108184-3.c: Adjust. --- gcc/config/rs6000/rs6000.cc | 5 +---- gcc/testsuite/gcc.target/powerpc/pr108184-3.c | 17 ++++++++++++----- 2 files changed, 13 insertions(+), 9 deletions(-) -- 2.27.0 diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc index f47d21980a9..870525347d5 100644 --- a/gcc/config/rs6000/rs6000.cc +++ b/gcc/config/rs6000/rs6000.cc @@ -25688,10 +25688,7 @@ rs6000_call_aix (rtx value, rtx func_desc, rtx tlsarg, rtx cookie) /* Can we optimize saving the TOC in the prologue or do we need to do it at every call? */ - if (TARGET_SAVE_TOC_INDIRECT - && !cfun->calls_alloca - && (rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT - || optimize_function_for_speed_p (cfun))) + if (TARGET_SAVE_TOC_INDIRECT && !cfun->calls_alloca) cfun->machine->save_toc_in_prologue = true; else { diff --git a/gcc/testsuite/gcc.target/powerpc/pr108184-3.c b/gcc/testsuite/gcc.target/powerpc/pr108184-3.c index ceaa96e4421..a1ce3a18855 100644 --- a/gcc/testsuite/gcc.target/powerpc/pr108184-3.c +++ b/gcc/testsuite/gcc.target/powerpc/pr108184-3.c @@ -2,15 +2,22 @@ /* { dg-require-effective-target fpic } */ /* { dg-options "-fpic -mno-pcrel -O2" } */ -/* Verify it doesn't imply -msave-toc-indirect, so - it doesn't take effect and we have two separated - toc savings for these two long calls. */ +/* Verify -msave-toc-indirect is implicitly enabled + for both optimizing for speed and size, so one + toc saving for each function. */ void foo (void) __attribute__((__longcall__)); int baz (void) __attribute__((__longcall__)); -__attribute__ ((cold)) int -bar (void) +__attribute__ ((cold, noipa)) int +bar1 (void) +{ + foo (); + return baz () + 1; +} + +__attribute__ ((noipa)) int +bar2 (void) { foo (); return baz () + 1;