Message ID | 236aab6b-537f-7fb6-125c-220fb63f7521@linux.ibm.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp565845vqo; Wed, 19 Apr 2023 10:54:04 -0700 (PDT) X-Google-Smtp-Source: AKy350ZYLDWJ7AZxzH6qKrGNCke+mhdGRZLaif6C+Y4+X3JHLQnRPlXCu+5bYwH2flhogKs6hg7i X-Received: by 2002:aa7:d4ce:0:b0:502:a92a:6532 with SMTP id t14-20020aa7d4ce000000b00502a92a6532mr6746530edr.20.1681926844511; Wed, 19 Apr 2023 10:54:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1681926844; cv=none; d=google.com; s=arc-20160816; b=k4jNQygDOH4xAfnCIEJ0qq7+bqbTWT6MJsSvl/HOeVI2efD6FGeCr7zt048C9OugUj hX1iA1EHFkheSRkfSHmTE109O2YAllkOGyZrTTqXVb/GBYhODe3djgyMT4u/dsI/fz3R /SAsIb7A0eI0EKfw0u/9IrvvhrZ/ScNMLrEHYzRd7oHZujqyg9ApTAumCYxcdS2CFhIW ph+eYg1yUq+awX4RbLoC19+dAYCAfsuAi3kLzuQka25tLlbXsrZdQBIL3QinbsUNZqXW urZBWcdzg+9i7fA8+AsMMNGL/Tl7MFKaTZRj2nqEnFENVeSRqnmHqldmUUSWcEAAC1IY USXg== 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-transfer-encoding:subject:cc:to:content-language:user-agent :mime-version:date:message-id:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=bFKz7Y9LNRb9PT0+MYPcmGuZI+OJewDr6qkj3+OeK7c=; b=ScBg7Ef9uu3HIrlRPgRqiz3hw+1wk4dhvrlQXDwePr16og6PEyadZny88D1eX5f54b Q8IonOg740HJMtLsMFV9pR3vQn+isYJyxBIXtSqBiiTzq2C1Kt5b6zF0xuBRoW3m53jV balAQcztRL0JHY4Igu/zwOuB3hjBThongL36ATvvGfis0DAciKto90HSuEQCleaelSLh knr6r33wr8vVOIGQSrdH5SVA0FFvs65oJrR28bJYuZbzRGavDCUEv7fMoEBs3Fa5+M8o siMLCQpAkgeotOWAHVIbilyX0XGCPsfI8WGemBjBKw0oq4gwmexytYWDXD9VWuZzCS/O Mhuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=m4Gry4ds; 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 b14-20020a05640202ce00b004ad7a9f7929si14781474edx.136.2023.04.19.10.54.04 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 10:54:04 -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=m4Gry4ds; 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 29E573857720 for <ouuuleilei@gmail.com>; Wed, 19 Apr 2023 17:54:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 29E573857720 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1681926843; bh=bFKz7Y9LNRb9PT0+MYPcmGuZI+OJewDr6qkj3+OeK7c=; h=Date:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=m4Gry4dseFt5+AC/Qq6Ck79d09o4hQdcIzMAjuM4eVrxwTL/EA/Up5/LwTmOxYeZE iN1gRUZlQWBomB+rtP0cNDusHDAmvmiIoWX5S2suhTZ7Dqu9S0Kge5ns4/EBiZ8T4g OCD2Jhbci/ZzEOawip/NGt4cjHH9OXRCAG/riJAQ= 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 04EE53858C31 for <gcc-patches@gcc.gnu.org>; Wed, 19 Apr 2023 17:53:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04EE53858C31 Received: from pps.filterd (m0187473.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33JH315r034966; Wed, 19 Apr 2023 17:53:14 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3q2apn5wje-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Apr 2023 17:53:14 +0000 Received: from m0187473.ppops.net (m0187473.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 33JHHugf027721; Wed, 19 Apr 2023 17:53:14 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3q2apn5wj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Apr 2023 17:53:13 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 33JGSaLE026556; Wed, 19 Apr 2023 17:53:13 GMT Received: from smtprelay07.wdc07v.mail.ibm.com ([9.208.129.116]) by ppma02dal.us.ibm.com (PPS) with ESMTPS id 3q1uxdgcje-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Apr 2023 17:53:12 +0000 Received: from smtpav06.wdc07v.mail.ibm.com (smtpav06.wdc07v.mail.ibm.com [10.39.53.233]) by smtprelay07.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 33JHrB2p10158604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Apr 2023 17:53:11 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7BC7D5803F; Wed, 19 Apr 2023 17:53:11 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5A9858054; Wed, 19 Apr 2023 17:53:08 +0000 (GMT) Received: from [9.43.84.11] (unknown [9.43.84.11]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTP; Wed, 19 Apr 2023 17:53:08 +0000 (GMT) Message-ID: <236aab6b-537f-7fb6-125c-220fb63f7521@linux.ibm.com> Date: Wed, 19 Apr 2023 23:23:07 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US To: gcc-patches <gcc-patches@gcc.gnu.org> Cc: jeff Law <jeffreyalaw@gmail.com>, segher Boessenkool <segher@kernel.crashing.org>, Peter Bergner <bergner@linux.ibm.com>, jakub Jelinek <jakub@redhat.com>, Richard Biener <richard.guenther@gmail.com> Subject: [PATCH v3 1/4] ree: Default ree pass for O2 and above for rs6000 target. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: sV75MtEvGXcvUl5kfIfrUzlzyN5_LxAF X-Proofpoint-GUID: z_kXri9reZ3YKFvYQJ2-bKk8l5FkvWwR X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-19_12,2023-04-18_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 adultscore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 bulkscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304190155 X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Ajit Agarwal via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Ajit Agarwal <aagarwa1@linux.ibm.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763628122990310609?= X-GMAIL-MSGID: =?utf-8?q?1763628122990310609?= |
Series |
[v3,1/4] ree: Default ree pass for O2 and above for rs6000 target.
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Ajit Agarwal
April 19, 2023, 5:53 p.m. UTC
Hello All: This is the patch-1 for improving ree pass for rs6000 target. Bootstrapped and regtested on powerpc64-linux-gnu. Thanks & Regards Ajit ree: Improve ree pass for rs6000 target. Add ree pass as a default pass for rs6000 target. 2023-04-19 Ajit Kumar Agarwal <aagarwa1@linux.ibm.com> gcc/ChangeLog: * common/config/rs6000/rs6000-common.cc: Add REE pass as a default rs6000 target pass for O2 and above. --- gcc/common/config/rs6000/rs6000-common.cc | 2 ++ 1 file changed, 2 insertions(+)
Comments
Hi! The subject should be something like rs6000: Enable REE pass by default (and no period at the end). On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote: > This is the patch-1 for improving ree pass for rs6000 target. It actually just enables it :-) The mail body should be the proposed commit message. Nothing more, nothing less. If you need (or want) to talk about more things, that is what a "0/4" message is for (you create that with --cover). Your patch messages here do not thread properly, how did you create them? Things work fine if you use git format-patch --thread :-) > ree: Improve ree pass for rs6000 target. > > Add ree pass as a default pass for rs6000 target. > > 2023-04-19 Ajit Kumar Agarwal <aagarwa1@linux.ibm.com> You aren't in MAINTAINERS yet, please fix that first! > > gcc/ChangeLog: > > * common/config/rs6000/rs6000-common.cc: Add REE pass as a > default rs6000 target pass for O2 and above. Why only for -O2? Only when optimising at all makes sense, people use -O0 only when they want to skip as many optimisations as possible, maybe because of compilation time concerns, maybe to avoid an ICE or other bug. Isn't REE *always* a good thing, it never degrades code quality? Or are there situations where it results in worse code? Segher
Hello Segher: On 20/04/23 1:30 am, Segher Boessenkool wrote: > Hi! > > The subject should be something like > > rs6000: Enable REE pass by default > > (and no period at the end). > > On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote: >> This is the patch-1 for improving ree pass for rs6000 target. > > It actually just enables it :-) > he c > The mail body should be the proposed commit message. Nothing more, > nothing less. If you need (or want) to talk about more things, that is > what a "0/4" message is for (you create that with --cover). Your patch > messages here do not thread properly, how did you create them? Things > work fine if you use git format-patch --thread :-) > >> ree: Improve ree pass for rs6000 target. >> >> Add ree pass as a default pass for rs6000 target. >> >> 2023-04-19 Ajit Kumar Agarwal <aagarwa1@linux.ibm.com> > > You aren't in MAINTAINERS yet, please fix that first! > >> Done. Already added Write after approval in MAINTAINERS and pushed the changes. >> gcc/ChangeLog: >> >> * common/config/rs6000/rs6000-common.cc: Add REE pass as a >> default rs6000 target pass for O2 and above. > > Why only for -O2? Only when optimising at all makes sense, people use > -O0 only when they want to skip as many optimisations as possible, maybe > because of compilation time concerns, maybe to avoid an ICE or other > bug. Isn't REE *always* a good thing, it never degrades code quality? > Or are there situations where it results in worse code? > I think it should be O2 and above and am not sure how it behaves with O0. According to me, REE is always a good optimization to have and I don't think it degrades any performance or code quality. I don't see any situation where it results in worse code. It tries to remove extensions and combine them which will surely improves performance and code quality instead of worsening the code. Thanks & Regards Ajit > Segher
On 4/19/23 3:00 PM, Segher Boessenkool wrote: > On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote: >> * common/config/rs6000/rs6000-common.cc: Add REE pass as a >> default rs6000 target pass for O2 and above. > > Why only for -O2? Only when optimising at all makes sense, people use > -O0 only when they want to skip as many optimisations as possible, maybe > because of compilation time concerns, maybe to avoid an ICE or other > bug. Isn't REE *always* a good thing, it never degrades code quality? > Or are there situations where it results in worse code? I think this is a case of following what the other architectures are doing. Namely, x86, aarch64, riscv, sparc, alpha and h8300 all enable -free at -O2 and above, not -O1. Not to say that is the best answer, but I think that is why we did the same. I agree I don't think -free can produce worse code which makes using it with -O1 and above an option. Maybe someone was worried about compile time??? Doesn't seem like an optimization like this would be too expensive though. Ajit, one thing that is missing from this specific patch is a change to gcc/doc/invoke.texi mentioning Power to the list of architectures that are enabling -free with the -O* options, which currently only mentions Alpha, AArch64 and x86. Being good community participants, it'd be good to add the missing riscv, sparc and h8300 when adding Power. Peter
On Mon, Apr 24, 2023 at 10:23:06AM -0500, Peter Bergner wrote: > On 4/19/23 3:00 PM, Segher Boessenkool wrote: > > On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote: > >> * common/config/rs6000/rs6000-common.cc: Add REE pass as a > >> default rs6000 target pass for O2 and above. > > > > Why only for -O2? Only when optimising at all makes sense, people use > > -O0 only when they want to skip as many optimisations as possible, maybe > > because of compilation time concerns, maybe to avoid an ICE or other > > bug. Isn't REE *always* a good thing, it never degrades code quality? > > Or are there situations where it results in worse code? > > I think this is a case of following what the other architectures are doing. > Namely, x86, aarch64, riscv, sparc, alpha and h8300 all enable -free at > -O2 and above, not -O1. Not to say that is the best answer, but I think > that is why we did the same. I agree I don't think -free can produce > worse code which makes using it with -O1 and above an option. Maybe someone > was worried about compile time??? Doesn't seem like an optimization like > this would be too expensive though. I thought that df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN); is quite expensive (only other pass which does that is SMS pass) and df_mir_add_problem (); as well (REE pass being the only user of that). As -O1 is meant to scale well on huge compiler generated functions, perhaps REE isn't appropriate for those by default. Jakub
On 4/24/23 10:28 AM, Jakub Jelinek wrote: > On Mon, Apr 24, 2023 at 10:23:06AM -0500, Peter Bergner wrote: >> On 4/19/23 3:00 PM, Segher Boessenkool wrote: >>> On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote: >>>> * common/config/rs6000/rs6000-common.cc: Add REE pass as a >>>> default rs6000 target pass for O2 and above. >>> >>> Why only for -O2? Only when optimising at all makes sense, people use >>> -O0 only when they want to skip as many optimisations as possible, maybe >>> because of compilation time concerns, maybe to avoid an ICE or other >>> bug. Isn't REE *always* a good thing, it never degrades code quality? >>> Or are there situations where it results in worse code? >> >> I think this is a case of following what the other architectures are doing. >> Namely, x86, aarch64, riscv, sparc, alpha and h8300 all enable -free at >> -O2 and above, not -O1. Not to say that is the best answer, but I think >> that is why we did the same. I agree I don't think -free can produce >> worse code which makes using it with -O1 and above an option. Maybe someone >> was worried about compile time??? Doesn't seem like an optimization like >> this would be too expensive though. > > I thought that > df_chain_add_problem (DF_UD_CHAIN + DF_DU_CHAIN); > is quite expensive (only other pass which does that is SMS pass) and > df_mir_add_problem (); > as well (REE pass being the only user of that). As -O1 is meant to scale > well on huge compiler generated functions, perhaps REE isn't appropriate > for those by default. Ah, so it is an issue with compile time then. If so, then sure, being -O2 and above makes sense then. Thanks for pointing that out! Peter
diff --git a/gcc/common/config/rs6000/rs6000-common.cc b/gcc/common/config/rs6000/rs6000-common.cc index 2140c442ba9..968db215028 100644 --- a/gcc/common/config/rs6000/rs6000-common.cc +++ b/gcc/common/config/rs6000/rs6000-common.cc @@ -34,6 +34,8 @@ static const struct default_options rs6000_option_optimization_table[] = { OPT_LEVELS_ALL, OPT_fsplit_wide_types_early, NULL, 1 }, /* Enable -fsched-pressure for first pass instruction scheduling. */ { OPT_LEVELS_1_PLUS, OPT_fsched_pressure, NULL, 1 }, + /* Enable -free for zero extension and sign extension elimination.*/ + { OPT_LEVELS_2_PLUS, OPT_free, NULL, 1 }, /* Enable -munroll-only-small-loops with -funroll-loops to unroll small loops at -O2 and above by default. */ { OPT_LEVELS_2_PLUS_SPEED_ONLY, OPT_funroll_loops, NULL, 1 },