From: will schmidt <will_schmidt@vnet.ibm.com>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: Segher Boessenkool <segher@kernel.crashing.org>,
David Edelsohn <dje.gcc@gmail.com>,
gcc-patches@gcc.gnu.org
Subject: Re: [PATCH,RS6000 2/5] Rework the RS6000_BTM defines.
Date: Tue, 07 Jun 2022 11:45:13 -0500 [thread overview]
Message-ID: <b8f775cd310af15d9f2d80c91c266d6f57caf160.camel@vnet.ibm.com> (raw)
In-Reply-To: <254e46d5-4f0d-00a4-a90c-ef914e1b600c@linux.ibm.com>
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_<xxxx> definitions are mostly unused after the
> > rs6000
> > builtin code was reworked. The remaining references can be
> > replaced
> > with the OPTION_MASK_<xxxx> and MASK_<xxxx> 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
next prev parent reply other threads:[~2022-06-07 16:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-06 21:52 [PATCH,RS6000 0/5] Clean up MASK_ and RS6000_BTM_ defines will schmidt
2022-06-06 22:05 ` [PATCH,RS6000 1/5] Clean-up MASK_<xxxx> and RS6000_BTM_<xxxx> definitions will schmidt
2022-06-06 22:05 ` [PATCH,RS6000 2/5] Rework the RS6000_BTM defines will schmidt
2022-06-07 2:50 ` Kewen.Lin
2022-06-07 16:45 ` will schmidt [this message]
2022-06-07 19:16 ` Segher Boessenkool
2022-06-06 22:05 ` [PATCH, RS6000 3/5] Rework the RS6000_BTM defines, continued will schmidt
2022-06-06 22:07 ` [PATCH,RS6000 5/5] Replace MASK_<xxxx> usage with OPTION_MASK_<xxxx> will schmidt
2022-06-06 22:07 ` [PATCH,RS6000 4/5] Replace MASK_<xxxx> " will schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b8f775cd310af15d9f2d80c91c266d6f57caf160.camel@vnet.ibm.com \
--to=will_schmidt@vnet.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linkw@linux.ibm.com \
--cc=segher@kernel.crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).