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 jos...@codesourcery.com
