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
> >>
>
