On Fri, May 29, 2009 at 09:02:23AM -0700, 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. > > 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))
As Ian says, we probably don't want to put a function where we check for each of the flags. This will likely be a major slowdown for the compiler. The trouble is as the compiler gets more complex, it is hard to find just where the right points to change things are, and what do you want to do about more global options. In my original thoughts about target specific support, I didn't include optimization because it was too hard, but quite a few potential users of it chimed in of the usefulness of marking a function as a cold function and compile with -Os instead of a hot function compiling with -O3. Unfortunately, I have been away from the code for about a year, that I don't remember all of the details of why particular choices were made. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
