Re: [PATCH] Rs6000 infrastructure cleanup (switches), revised patch #4

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

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