On 11/3/20 2:34 PM, Jakub Jelinek wrote:
On Tue, Nov 03, 2020 at 02:27:52PM +0100, Richard Biener wrote:
On Fri, Oct 23, 2020 at 1:47 PM Martin Liška <mli...@suse.cz> wrote:
This is a follow-up of the discussion that happened in thread about
no_stack_protector
attribute: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545916.html
The current optimize attribute works in the following way:
- 1) we take current global_options as base
- 2) maybe_default_options is called for the currently selected optimization
level, which
means all rules in default_options_table are executed
- 3) attribute values are applied (via decode_options)
So the step 2) is problematic: in case of -O2 -fno-omit-frame-pointer and
__attribute__((optimize("-fno-stack-protector")))
ends basically with -O2 -fno-stack-protector because -fno-omit-frame-pointer is
default:
/* -O1 and -Og optimizations. */
{ OPT_LEVELS_1_PLUS, OPT_fomit_frame_pointer, NULL, 1 },
My patch handled and the current optimize attribute really behaves that same as
appending attribute value
to the command line. So far so good. We should also reflect that in
documentation entry which is quite
vague right now:
"""
The optimize attribute is used to specify that a function is to be compiled
with different optimization options than specified on the command line.
"""
and we may want to handle -Ox in the attribute in a special way. I guess many
macro/pragma users expect that
-O2 -ftree-vectorize and __attribute__((optimize(1))) will end with -O1 and not
with -ftree-vectorize -O1 ?
Hmm. I guess the only two reasonable options are to append to the active set
and thus end up with -ftree-vectorize -O1 or to start from an empty set and thus
end up with -O1.
I'd say we always want to append, but only take into account explicit
options.
Yes, I also prefer to always append and basically drop the "reset"
functionality.
So basically get the effect of
take the command line, append to that options from the optimize/target
pragmas in effect and append to that options from optimize/target
attributes and only from that figure out the implicit options.
Few notes here:
- target and optimize attributes are separate so parsing happens independently;
however
they use global_options and global_options_set as a starting point
- you can have a series of wrapped optimize/pragma macros and again information
is shared
in global_options/global_options_set
- target and optimize options interact, but in a controlled way with
SET_OPTION_IF_UNSET
That said, I hope the biggest offender is right now the handling of -Olevel.
@Jakub: Do you see a situation with my patch where it breaks?
Thanks,
Martin
Jakub
