From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 2514E3857005 for ; Fri, 6 Nov 2020 17:34:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2514E3857005 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-398-TbwPk-MXPa6JWTNqBUQ2FQ-1; Fri, 06 Nov 2020 12:34:15 -0500 X-MC-Unique: TbwPk-MXPa6JWTNqBUQ2FQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 78BBE1009E2D; Fri, 6 Nov 2020 17:34:14 +0000 (UTC) Received: from localhost.localdomain (ovpn-114-181.phx2.redhat.com [10.3.114.181]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1E8B55D98F; Fri, 6 Nov 2020 17:34:14 +0000 (UTC) Subject: Re: [PATCH] Optimize macro: make it more predictable To: =?UTF-8?Q?Martin_Li=c5=a1ka?= , gcc-patches@gcc.gnu.org Cc: Jakub Jelinek , Michael Matz References: <82e71ebf-7b2e-67e7-1f08-ea525deee4cb@suse.cz> From: Jeff Law Message-ID: <2b4f60d1-3488-d014-8e79-bcf9bf52bdfe@redhat.com> Date: Fri, 6 Nov 2020 10:34:13 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <82e71ebf-7b2e-67e7-1f08-ea525deee4cb@suse.cz> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, 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: Fri, 06 Nov 2020 17:34:21 -0000 On 10/23/20 5:47 AM, Martin Liška wrote: > Hey. > > 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 ? > > I'm also planning to take a look at the target macro/attribute, I > expect similar problems: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469 > > Thoughts? > Thanks, > Martin > > gcc/c-family/ChangeLog: > >     * c-common.c (parse_optimize_options): Decoded attribute options >     with the ones that were already set on the command line. > > gcc/ChangeLog: > >     * toplev.c (toplev::main): Save decoded Optimization options. >     * toplev.h (save_opt_decoded_options): New. > > gcc/testsuite/ChangeLog: > >     * gcc.target/i386/avx512er-vrsqrt28ps-3.c: Disable -ffast-math. >     * gcc.target/i386/avx512er-vrsqrt28ps-5.c: Likewise. So you XNEWVEC and store the result into "merge_decoded_options".  But you free "decoded_options".  Was that intentional? This seems to bring a bit more predictability, but I suspect there's more to do here. jeff