On Mon, May 25, 2020 at 11:27 AM Martin Liška <mli...@suse.cz> wrote:
>
> On 5/22/20 12:51 PM, Richard Biener wrote:
> > 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 should work. Anyway, that's a task with unclear finish.
> Would it be possible to add the no_stack_protect attribute for the time being?
I think it's a reasonable request, yes.
Richard.
> The limitation is there for ages and we have another "optimize" attributes
> that can be theoretically replaced with proper optimize handling.
>
> >
> > 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).
>
> I fear from the interaction of optimization and target attribute.
>
> >
> > As you say, option handling is difficult.
>
> Anyway, I'm planning to work on the options in stage1. It's quite close
> relative to PR92860.
>
> Martin
>
> >
> > 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
> >>>>
> >>
>
