From: Michael Meissner <meissner@linux.vnet.ibm.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>
Cc: Michael Meissner <meissner@linux.vnet.ibm.com>,
David Edelsohn <dje.gcc@gmail.com>,
gcc-patches@gcc.gnu.org, bergner@vnet.ibm.com,
segher@kernel.crashing.org, iain@codesourcery.com,
andreast-list@fgznet.ch
Subject: Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4
Date: Tue, 16 Oct 2012 19:19:00 -0000 [thread overview]
Message-ID: <20121016183200.GA17037@ibm-tiger.the-meissners.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1210161449520.1826@digraph.polyomino.org.uk>
On Tue, Oct 16, 2012 at 03:02:47PM +0000, Joseph S. Myers wrote:
> That is:
>
> 1. Patch adding TARGET_FOO aliases for OPTION_FOO (small change to the awk
> scripts and associated documentation, I expect).
>
> 2. Large, mechanical, automatically generated patch to change existing
> OPTION_FOO users (or maybe one such patch per target).
I just grep'ed for OPTION_, filtering out OPTION_MASK_, TARGET_OPTION_OVERRIDE,
OPTION_DEFAULT_SPECS_*, OPTION_GLIBC, OPTION_UCLIBC, OPTION_BIONIC,
TARGET_OPTION_SAVE, TARGET_OPTION_RESTORE, TARGET_OPTION_PRINT,
OPTION_TARGET_CPU_DEFAULT, TARGET_OPTION_VALID_ATTRIBUTE_P, _SPEC[\" ],
MIPS_ARCH_*, TARGET_OPTION_*, RS6000_CPU_OPTION_NATIVE, and there is only one
place where OPTION_* is used as a test (config/linux-android.h). The only
other port to do OPTION_* is x86, and there they have a bunch of #defines that
map OPTION_<xxx> into TARGET_<xxx>. So it looks fairly straight forward to do
the conversion in one jump.
> 3. Patch removing the OPTION_FOO name (small change to awk scripts and
> documentation).
>
> Then you've eliminated one unnecessary cause of changes when moving bits
> out of target_flags.
>
> > If TargetName were defined, it would use TARGET_<xxx> instead of OPTION_<xxx>,
> > but the OPTION_MASK_<xxx> would not be changed.
>
> Not needed, given the above sequence of changes.
Yep, I would prefer not to have to add TargetName, though it is simple enough.
> > If SetFunction was defined, the opt*.awk files would generate:
> >
> > #define SET_FOO(VALUE) \
> > do { \
> > if (VALUE) \
> > target_flags &= ~MASK_FOO; \
> > else \
> > target_flags |= MASK_FOO; \
> > } while (0)
> >
> > If ExplicitFunction was defined, the opt*.awk files would generate:
> >
> > #define EXPLICIT_FOO(VALUE) \
> > ((global_options_set.x_target_flags & MASK_FOO) != 0)
>
> I'd like any such new macros to take an argument that's the pointer to the
> relevant options structure (global_options, global_options_set). If the
> place where the macro is called has a pointer available, then it can be
> passed in, otherwise pass in &global_options or &global_options_set unless
> and until such a pointer becomes available in the relevant place.
It occurs to me that now that we've committed to GCC being done in C++, we
could just make global_options{,_set} be a class instead of a structure. So
you could say:
global_options.set_FOO (value)
Or:
global_options.set_FOO ();
global_options.clear_FOO ();
I could generate the macros (or inline functions) if you would prefer to stick
the C style of doing things. However, as an old C dinosaur, I'm not sure of
all of the ramifications of doing this. It just seems it would be cleaner to
use the class structure, instead of passing pointers.
> > How would you feel about SetFunction, ExplicitFunction, and the reduced
> > TargetName?
>
> The principle of having macros for setting flags or testing if they are
> explicitly set is fine, though it's not clear to me that they need any
> such special settings as SetFunction and ExplicitFunction (rather than
> being generated unconditionally).
Yes, it is simpler not to have to add another flag. I was just trying to be
conservative in generating things other ports might not reference.
> I'd quite like the macros such as target_flags that refer to global
> options to end up not being lvalues at all. That helps ensure that option
> settings are only modified in limited places that have options pointers.
> It would be nice eventually for such things as "optimize" and "target"
> attributes to be able to swap options structures, and to work closer to
> how options on the command line are processed - for that, you want careful
> control on what places actually modify options at all.
Yep, though unfortunately that are various ports that do want to change
optimization options if not set.
--
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meissner@linux.vnet.ibm.com fax +1 (978) 399-6899
next prev parent reply other threads:[~2012-10-16 18:32 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 22:44 [PATCH] Rs6000 infrastructure cleanup (switches) Michael Meissner
2012-09-15 16:49 ` Andreas Tobler
2012-09-17 17:04 ` Michael Meissner
2012-09-17 8:21 ` Iain Sandoe
2012-09-17 17:12 ` Michael Meissner
2012-09-17 19:52 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch Michael Meissner
2012-09-19 0:04 ` David Edelsohn
2012-09-19 20:00 ` Michael Meissner
2012-09-20 20:12 ` Michael Meissner
2012-09-27 22:57 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2b Michael Meissner
2012-09-28 19:24 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c Michael Meissner
2012-10-01 23:11 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2d Michael Meissner
2012-10-02 17:44 ` David Edelsohn
2012-10-02 8:13 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c Gunther Nikl
2012-10-02 16:12 ` Michael Meissner
2012-10-04 16:33 ` Gunther Nikl
2012-10-05 18:17 ` Michael Meissner
2012-10-05 18:48 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #3 Michael Meissner
2012-10-06 19:47 ` Gunther Nikl
2012-10-06 20:08 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c Gunther Nikl
2012-10-04 1:42 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2b David Edelsohn
2012-10-05 18:31 ` Michael Meissner
2012-10-05 19:49 ` Michael Meissner
2012-10-09 23:01 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2c Michael Meissner
2012-10-10 1:17 ` David Edelsohn
2012-10-09 23:20 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2d Michael Meissner
2012-10-10 1:18 ` David Edelsohn
2012-10-09 23:37 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2e Michael Meissner
2012-10-10 1:32 ` David Edelsohn
2012-10-09 23:39 ` [PATCH] Rs6000 infrastructure cleanup (switches), question Michael Meissner
2012-10-10 16:56 ` David Edelsohn
2012-10-13 6:13 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4 Michael Meissner
2012-10-15 15:58 ` Joseph S. Myers
2012-10-15 16:43 ` Michael Meissner
2012-10-16 15:10 ` Joseph S. Myers
2012-10-16 19:19 ` Michael Meissner [this message]
2012-10-16 22:50 ` [PATCH] TARGET_<xxx> support, was [PATCH] Rs6000 infrastructure cleanup Michael Meissner
2012-10-16 23:54 ` Richard Henderson
2012-10-17 9:55 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4 Joseph S. Myers
2012-10-17 19:54 ` Michael Meissner
2012-10-16 16:13 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2f Michael Meissner
2012-10-17 19:42 ` David Edelsohn
2012-10-17 20:48 ` Michael Meissner
2012-10-18 15:46 ` Eric Botcazou
2012-09-27 22:56 ` [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #2 Michael Meissner
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=20121016183200.GA17037@ibm-tiger.the-meissners.org \
--to=meissner@linux.vnet.ibm.com \
--cc=andreast-list@fgznet.ch \
--cc=bergner@vnet.ibm.com \
--cc=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=iain@codesourcery.com \
--cc=joseph@codesourcery.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).