From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 21762382D535 for ; Tue, 7 Jun 2022 16:45:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21762382D535 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 257G6GrI017010; Tue, 7 Jun 2022 16:45:16 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3gj9jbhb70-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 16:45:16 +0000 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 257GYaws004423; Tue, 7 Jun 2022 16:45:16 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 3gj9jbhb6m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 16:45:16 +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 257GKMqS025437; Tue, 7 Jun 2022 16:45:14 GMT Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by ppma02wdc.us.ibm.com with ESMTP id 3gfy19nga2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Jun 2022 16:45:14 +0000 Received: from b01ledav005.gho.pok.ibm.com (b01ledav005.gho.pok.ibm.com [9.57.199.110]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 257GjEC97865238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 7 Jun 2022 16:45:14 GMT Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 59645AE05F; Tue, 7 Jun 2022 16:45:14 +0000 (GMT) Received: from b01ledav005.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E2BD3AE05C; Tue, 7 Jun 2022 16:45:13 +0000 (GMT) Received: from lexx (unknown [9.160.81.62]) by b01ledav005.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 7 Jun 2022 16:45:13 +0000 (GMT) Message-ID: Subject: Re: [PATCH,RS6000 2/5] Rework the RS6000_BTM defines. From: will schmidt To: "Kewen.Lin" Cc: Segher Boessenkool , David Edelsohn , gcc-patches@gcc.gnu.org Date: Tue, 07 Jun 2022 11:45:13 -0500 In-Reply-To: <254e46d5-4f0d-00a4-a90c-ef914e1b600c@linux.ibm.com> References: <21f1b472875d5c75e151e647c5182a74e426559f.camel@vnet.ibm.com> <82211644fb1f61894e5b99a7c5fdb8e73539ddc0.camel@vnet.ibm.com> <254e46d5-4f0d-00a4-a90c-ef914e1b600c@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-18.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: W_lO12PVxwZe4sQoReVszsqvvio6WI4B X-Proofpoint-ORIG-GUID: -4zp-iXo_V_Bdeht-KSDdI_lKuYeJ0U_ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.517,FMLib:17.11.64.514 definitions=2022-06-07_07,2022-06-07_02,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 bulkscore=0 phishscore=0 malwarescore=0 adultscore=0 mlxscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000 definitions=main-2206070067 X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, 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-List-Received-Date: Tue, 07 Jun 2022 16:45:20 -0000 On Tue, 2022-06-07 at 10:50 +0800, Kewen.Lin wrote: > Hi Will, Hi! > > The whole series looks good to me, thanks! :-) > IMHO one place can be > further refactored, not sure if it's worth to updating together in > this series, it's ... Additional comments below. I've made note of the comments, and request (ask) that this be approved, with a pinky promise that I intend to follow up on the suggestions in my next patch series. > > on 2022/6/7 06:05, will schmidt wrote: > > [PATCH,RS6000 2/5) Rework the RS6000_BTM defines. > > > > The RS6000_BTM_ definitions are mostly unused after the > > rs6000 > > builtin code was reworked. The remaining references can be > > replaced > > with the OPTION_MASK_ and MASK_ equivalents. > > > > This patch remvoes the defines: > > RS6000_BTM_FRES, RS6000_BTM_FRSQRTE, RS6000_BTM_FRSQRTES, > > RS6000_BTM_POPCNTD, RS6000_BTM_CELL, RS6000_BTM_DFP, > > RS6000_BTM_HARD_FLOAT, RS6000_BTM_LDBL128, RS6000_BTM_64BIT, > > RS6000_BTM_POWERPC64, RS6000_BTM_FLOAT128, RS6000_BTM_FLOAT128_HW > > RS6000_BTM_MMA, RS6000_BTM_P10. > > > > I note that the BTM -> OPTION_MASK mappings are not always 1-to-1. > > in particular the BTM_FRES and BTM_FRSQRTE values were both mapped > > to > > OPTION_MASK_PPC_GFXOPT, while the BTM_FRE and BTM_FRSQRTES both > > mapped > > to OPTION_MASK_POPCNTB. In total I spent quite a bit of time > > double-checking these since it looked like copy/paste errors. I > > split > > some of these changes out into a subsequent patch to limit the > > amount > > of potential confusion in any particular patch. > > > > gcc/ > > * config/rs6000/rs6000-c.cc: Update comments. > > * config/rs6000/rs6000.cc (RS6000_BTM_FRES, RS6000_BTM_FRSQRTE, > > RS6000_BTM_FRSQRTES, RS6000_BTM_POPCNTD, RS6000_BTM_CELL, > > RS6000_BTM_64BIT, RS6000_BTM_POWERPC64, RS6000_BTM_DFP, > > RS6000_BTM_HARD_FLOAT,RS6000_BTM_LDBL128, RS6000_BTM_FLOAT128, > > RS6000_BTM_FLOAT128_HW, RS6000_BTM_MMA, RS6000_BTM_P10): > > Replace > > with OPTION_MASK_PPC_GFXOPT, OPTION_MASK_PPC_GFXOPT, > > OPTION_MASK_POPCNTB, OPTION_MASK_POPCNTD, > > OPTION_MASK_FPRND, MASK_64BIT, MASK_POWERPC64, > > OPTION_MASK_DFP, OPTION_MASK_SOFT_FLOAT, OPTION_MASK_MULTIPLE, > > OPTION_MASK_FLOAT128_KEYWORD, OPTION_MASK_FLOAT128_HW, > > OPTION_MASK_MMA, OPTION_MASK_POWER10. > > * config/rs6000/rs6000.h (RS6000_BTM_FRES, RS6000_BTM_FRSQRTE, > > RS6000_BTM_FRSQRTES, RS6000_BTM_POPCNTD, RS6000_BTM_CELL, > > RS6000_BTM_DFP, RS6000_BTM_HARD_FLOAT, RS6000_BTM_LDBL128, > > RS6000_BTM_64BIT, RS6000_BTM_POWERPC64, RS6000_BTM_FLOAT128, > > RS6000_BTM_FLOAT128_HW, RS6000_BTM_MMA, RS6000_BTM_P10): > > Delete. > > > > diff --git a/gcc/config/rs6000/rs6000-c.cc > > b/gcc/config/rs6000/rs6000-c.cc > > index 9c8cbd7a66e4..4c99afc761ae 100644 > > --- a/gcc/config/rs6000/rs6000-c.cc > > +++ b/gcc/config/rs6000/rs6000-c.cc > > @@ -594,13 +594,13 @@ rs6000_target_modify_macros (bool define_p, > > HOST_WIDE_INT flags, > > via the target attribute/pragma. */ > > if ((flags & OPTION_MASK_FLOAT128_HW) != 0) > > rs6000_define_or_undefine_macro (define_p, > > "__FLOAT128_HARDWARE__"); > > > > /* options from the builtin masks. */ > > - /* Note that RS6000_BTM_CELL is enabled only if (rs6000_cpu == > > - PROCESSOR_CELL) (e.g. -mcpu=cell). */ > > - if ((bu_mask & RS6000_BTM_CELL) != 0) > > + /* Note that OPTION_MASK_FPRND is enabled only if > > + (rs6000_cpu == PROCESSOR_CELL) (e.g. -mcpu=cell). */ > > + if ((bu_mask & OPTION_MASK_FPRND) != 0) > > rs6000_define_or_undefine_macro (define_p, "__PPU__"); > > > > ... here. In function rs6000_target_modify_macros, bu_mask is used > by > two places, the beginning debug outputting and the above > OPTION_MASK_FPRND > check. I wonder if we can get rid of bu_mask and just use sth. like: > > (rs6000_cpu == PROCESSOR_CELL) && (flags & OPTION_MASK_FPRND) > Agreed. > // the others are using "flags &", it's passed by rs6000_isa_flags, > // should be the same as just using OPTION_MASK_FPRND. > > If we drop bu_mask in function rs6000_target_modify_macros, function > rs6000_builtin_mask_calculate will have only one use place in > function > rs6000_option_override_internal. IMHO this function > rs6000_builtin_mask_calculate also becomes stale after built-in > function > rewriting and needs some updates with new bif framework later. The DEBUG output using the builtin_mask still appeared to have some potential value, but I can make a point to investigate that further. I do have in my queue to try to resolve PR 101865, that is the bug with ARCH_PWR8. I got into this OPTION_MASK side-quest as part of the investigation into that bug. I can make a point to investigate and clean up the bu_mask usage as part of that series. Thanks -Will > > BR, > Kewen