From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 713293896802 for ; Mon, 7 Dec 2020 11:03:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 713293896802 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mliska@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 56379AC9A; Mon, 7 Dec 2020 11:03:47 +0000 (UTC) Subject: Re: [PATCH] Optimize macro: make it more predictable From: =?UTF-8?Q?Martin_Li=c5=a1ka?= To: Jakub Jelinek , Richard Biener Cc: Michael Matz , GCC Patches References: <82e71ebf-7b2e-67e7-1f08-ea525deee4cb@suse.cz> <20201103133446.GO3788@tucnak> <0cca4c25-78ab-6eaf-4a73-03474373d33a@suse.cz> Message-ID: <68745cd7-e6d3-445b-1322-6d5b3eff0c37@suse.cz> Date: Mon, 7 Dec 2020 12:03:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <0cca4c25-78ab-6eaf-4a73-03474373d33a@suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 11:03:50 -0000 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 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 >>> >> >