On Thu, May 21, 2020 at 12:09 PM Martin Liška <mli...@suse.cz> wrote: > > On 5/18/20 1:49 PM, Richard Biener wrote: > > On Mon, May 18, 2020 at 1:10 PM Jakub Jelinek via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> > >> On Mon, May 18, 2020 at 01:03:40PM +0200, Jakub Jelinek wrote: > >>>> The optimize attribute is used to specify that a function is to be > >>>> compiled > >>>> with different optimization options than specified on the command line. > >>>> ``` > >>>> > >>>> It's pretty clear about the command line arguments (that are ignored). > >>> > >>> That is not clear at all. The difference is primarily in what the option > >>> string says in there. > >> > >> And if we decide we want to keep existing behavior (haven't checked if we > >> actually behave that way yet), we should add some syntax that will allow > >> ammending command line options rather than replacing it. > > Hello. > > Back to this, I must say that option handling is a complex thing in the GCC. > > > > > We do behave this way - while we're running against the current > > gcc_options we call decode_options which first does > > default_options_optimization. So it behaves inconsistently with > > respect to options not explicitly listed in default_options_table. > > Yes, we basically build on top of the currently selection flags. > We use default_options_table because any optimization level selection > in an optimization attribute should efficiently enforce call of > default_options_table. > > What about using them only in case one changes optimization level (patch)?
I'm not sure if that works, no -On means -O0, so one might interpret optimize("omit-frame-pointer") as -O0 -fomit-frame-pointer. Also -On are not treated in position dependent way, thus -fno-tree-pre -O2 is the same as -O2 -fno-tree-pre rather than re-enabling PRE over -fno-tree-pre. So your patch would turn a -O2 -fno-tree-pre invocation, when optimize("O3") is encountered, to one with PRE enabled, not matching behavior of -O2 -fno-tree-pre -O3. I think the only sensible way is to save the original decoded options from the gcc invocation (and have #pragma optimize push/pop append accordingly) and append the current attribute/pragmas optimization string to them and run that whole thing on a default option state. That makes semantics equivalent to appending more options to the command-line. Well, hopefully. Interaction with the target attribute might be interesting (that likely also needs to append to that "current decoded options" set). As you say, option handling is difficult. Richard. > Martin > > > > > But I also think doing the whole processing as in decode_options > > is the only thing that's really tested. And a fix would be to not > > start from the current set of options but from a clean slate... > > > > The code clearly thinks we're doing incremental changes: > > > > /* Save current options. */ > > cl_optimization_save (&cur_opts, &global_options); > > > > /* If we previously had some optimization options, use them as the > > default. */ > > if (old_opts) > > cl_optimization_restore (&global_options, > > TREE_OPTIMIZATION (old_opts)); > > > > /* Parse options, and update the vector. */ > > parse_optimize_options (args, true); > > DECL_FUNCTION_SPECIFIC_OPTIMIZATION (*node) > > = build_optimization_node (&global_options); > > > > /* Restore current options. */ > > cl_optimization_restore (&global_options, &cur_opts); > > > > so for example you should see -fipa-pta preserved from the > > command-line while -fno-tree-pta would be overridden even > > if not mentioned explicitely in the optimize attribute. > > > > IMHO the current situation is far from useful... > > > > Richard. > > > >> Could be say start the optimize attribute string with + or something > >> similar. > >> Does target attribute behave that way too? > >> > >> Jakub > >> >