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