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
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
