Re: [PATCH] Optimize macro: make it more predictable

["Martin Liška" <mliska@suse.cz>]

I'm suggesting postponing this to GCC 12 as I'm planning a bigger
target/optimize attribute (pragma) overhaul.

Martin

On 12/7/20 12:03 PM, Martin Liška wrote:
> PING^2
> 
> On 11/26/20 2:56 PM, Martin Liška wrote:
>> PING^1
>>
>> On 11/9/20 11:35 AM, Martin Liška wrote:
>>> 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 <mliska@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
>>>>
>>>
>>
>