Re: RFC: Option handling and PR 37565

[Steve Ellcey <sje at cup dot hp dot com>]

On Fri, 2009-05-29 at 16:56 +0000, Joseph S. Myers wrote:

> I don't really feel that either the original proposal or this one is any 
> cleaner than what we have right now, and the original proposal is at least 
> simpler.  As neither really addresses the general issues with how options 
> are handled (as I see them), on the whole I'd prefer the simpler way of 
> fixing the bug that is at least easier to tear out later.

I thought my proposal was cleaner because we could have a rule that says
flags are only changed by user specified flags and by the optimize
attribute.  target code could look at those values and other variables
to determine if it wanted to do a particular optimization or not but it
wouldn't ever change the flag value that was set on the command line or
by the attribute.

> Both proposals involve new target hooks or macros, moving ad hoc code 
> around rather than eliminating it.  These can use arbitrary C code to 
> manipulate option state.  This is very flexible, but flexibility can be 
> bad; we want consistent rules in GCC for how partially overlapping or 
> overriding options should interact, for example, and it should be hard for 
> particular targets or options to break those consistent rules 
> accidentally.  Consistency tends to argue for making .opt files more 
> expressive rather than proliferating hooks or macros.

I think that what I want to do is remove the manipulating (changing) of
the option state completely (except by user flags and the optimization
attribute) and make the use/access of that state more flexible then just
checking a single flag.

> Where you suggest:
> 
> > My idea is that we would never change the values of the flags that are
> > set by the user but instead would have a target overridable function
> > that returns the value for a given flag by default but in which the
> > return value could be overridden for some flags on some targets.
> > 
> > So instead of 
> > 	if (flag_var_tracking)
> > we would have
> > 	if (targetm.get_optimization_flag_value(OPT_fvar_tracking))
> 
> I'd instead suggest
> 
> #define flag_var_tracking ((int) global_options.optimization.fvar_tracking)
> 
> (automatically generated) or similar.  The cast makes it not an lvalue, 
> which is a good idea because I also don't want random code changing the 
> options; changes to the structure should be limited to particular places 
> (automatically generated from .opt files where possible) receiving a 
> pointer to the particular structure they are to change.

That would fix Ian's complaint about an indirect function call but it
still means that the decision to do or not do var_tracking is kept in a
single variable that might or might not need to be overridden in some
case.  But I guess in your proposal something in the opt file would tell
us if we want to override the default behaviour for var_tracking and
generate the code that would change it's value from the default.

Steve Ellcey
sje@cup.hp.com