Re: RFC: Option handling and PR 37565

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 29 May 2009, Steve Ellcey wrote:

> While looking into PR 37565 I began to wonder if we need to modify how
> we handle optimization flag handling.  Currently we have
> OVERRIDE_OPTIONS, C_COMMON_OVERRIDE_OPTIONS, and OPTIMIZATION_OPTIONS to
> set or override the optimization flags a user gives.  One proposal to
> fix 37565 was to split OVERRIDE_OPTIONS into OVERRIDE_OPTIONS_ALWAYS and
> OVERRIDE_OPTIONS_ONCE  which would create two new macros.
> 
> But I was wondering if a cleaner method to deal with these options would
> be to get rid of all these macros and use target functions to access
> flag values.

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.

The way I see it, the basic problem is the large amount of ad hoc code, 
much of it target-specific, handling options, their defaults and their 
interactions.  The PR you mention is one problem arising from this; it's 
difficult for options in optimize attributes to work like those on the 
command line.  Another group of problems relate to specs and multilib 
selection; these have no access to the code in the compiler proper 
handling option interactions and defaults and instead make piecemeal 
attempts to replicate bits of that logic, badly.

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.

My general idea is that there should be some sort of object for the 
compiler global state - both target-dependent and and target-independent - 
derived from the command line.  (The cl_optimization structure is a useful 
start to this.)  The compiler should maintain several such objects at 
once.  There would be one for the command line immediately after being 
parsed, before any defaults get applied that would be affected by optimize 
attributes, and a global one with defaults applied that is used by 
references to flag variables.  optimize attributes might create a 
function-local options structure by copying the pre-defaults one, applying 
the function-local options to it and then calling the hooks to apply 
defaults to that structure.  Multilib selection might compute structures 
for each multilib and match them to the structure for the command line.

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.

I think any solution other than a temporary, minimally intrusive fix for 
specific bugs that have been found needs to start with a detailed analysis 
of how and why the present hooks are used in existing targets, resulting 
in an understanding of the requirements for a solution and proposals for 
consistent rules on how options interact.

-- 
Joseph S. Myers
joseph@codesourcery.com