From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) by sourceware.org (Postfix) with ESMTPS id 762193889800 for ; Wed, 11 May 2022 21:25:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 762193889800 Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-2fb965b34easo36294597b3.1 for ; Wed, 11 May 2022 14:25:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=euvL0h01XATdfbOBbl9vdn+m0rbXX6ak8SpkHZW2kIU=; b=MXnFqE3Li1Oe2iBF8irsuoo1/zZF73LemhOmQpD+8b+/B5wniT1f1kfb8OV+QT/OZQ NENOUDZxnMUsurUFjiu4X3Vbej9VqZa96gyFbVmcRW2AnbwRvY00knIBkXzEtNStYQpX cBOP/HGLZfz/esRlwiD51IyPGAIwxoOP1oMNO/FQJG1fBh6wgwJpmsaBA7DMdd2+EmqC 2s/vgeivZ4af1hJ3/3nkb0FsPoVTXWdkr3hZcjww1RfNGHi9dOMOce92llkFWvATVCWb bJdLRqL1afY2Xfbv7vN5qF5AMrTM9G0NYAdstRzderH3475utoI2YkitKcb4A4X8gLmW OC0w== X-Gm-Message-State: AOAM530jozYAluIU22nwhtADnC12/yGaZsfD+YFOZjsbmynQcltPx5Ju Eqe9fk5gezU+lYxwOAiwSaxXpXXA6Pe+XNP2SEH3Wg== X-Google-Smtp-Source: ABdhPJys4JyKs/r9aXNXJQ1sNjcLo5PUrL6eZCzw2GeDt+//66SmnkB4mhvfly1eIe4nogquewRv1fxQ948dyBX38qo= X-Received: by 2002:a81:5603:0:b0:2f8:3187:f37a with SMTP id k3-20020a815603000000b002f83187f37amr26299355ywb.255.1652304322624; Wed, 11 May 2022 14:25:22 -0700 (PDT) MIME-Version: 1.0 References: <20211118173123.GC76860@kam.mff.cuni.cz> <20211119115101.GA57358@kam.mff.cuni.cz> In-Reply-To: From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Wed, 11 May 2022 14:25:11 -0700 Message-ID: Subject: Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition To: Martin Jambor Cc: Jan Hubicka , GCC Patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-16.9 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, KAM_INFOUSMEBIZ, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Wed, 11 May 2022 21:25:25 -0000 On Fri, Nov 19, 2021 at 9:55 AM Martin Jambor wrote: > > Hi, > > On Fri, Nov 19 2021, Jan Hubicka wrote: > >> > Hi, > >> > > >> > On Fri, Nov 12 2021, Martin Jambor wrote: > >> > > Hi, > >> > > > >> > > using -fno-semantic-interposition has been reported by various peo= ple > >> > > to bring about considerable speed up at the cost of strict complia= nce > >> > > to the ELF symbol interposition rules See for example > >> > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositi= onSpeedup > >> > > > >> > > As such I believe it should be implied by our -Ofast optimization > >> > > level, not only so that benchmarks that can benefit run faster, bu= t > >> > > also so that people looking at -Ofast documentation for options th= at > >> > > could speed their programs find it. > >> > > > >> > > I have verified that with the following patch IPA-CP sees > >> > > flag_semantic_interposition set to zero at Ofast and that info and= pdf > >> > > manual builds fine with the documentation change. I am bootstrapp= ing > >> > > and testing it now in order to comply with submission criteria but= I > >> > > don't think an Ofast change gets much tested. > >> > > > >> > > Assuming it passes, is the patch OK? (If it is, I will also add a= note > >> > > about it in the "Caveats" section in gcc-12/changes.html of wwwdoc= s > >> > > after I commit the patch.) > >> > > > >> > > >> > Unfortunately, I was wrong, there are testcases which use the optimi= ze > >> > attribute to switch a function to Ofast and those ICE because > >> > -fsemantic-interposition is not an optimization flag and only > >> > optimization flags can change in an optimize attribute (AFAIK, I onl= y > >> > had a quick glance at the results). > >> > > >> > I am not sure what is the right way to tackle this, whether to set t= he > >> > flag at Ofast in some nonstandard way or make the flag an optimizati= on > >> > flag - probably affecting function definitions, having it affect > >> > call-sites seems too fine-grained. I will try to discuss this on IR= C on > >> > Monday (and hope such change is still doable early stage3). > >> > > >> > Sorry for posting this a bit prematurely, > >> > >> Hi, > >> > >> This patch turns flag_semantic_interposition to optimization option so > >> it can be enabled with per-function granuality. This is done by addin= g > >> the flag among visibility flags into the symbol table. This fixes the > >> behaviour on the testcase I added to testsuite. > >> > >> There are bugs where get_availability misbehaves on partitioned progra= m. > >> We can also use the new flag to fix those, but I will do that > >> incrementally. > >> > >> The -Ofast change should be safe now. > > > > Also forgot to say it explicitly, the patch is OK, so please commit it. > > > > Thanks a lot for the enabling patch. I have committed mine after re-test= ing. > > Martin Perhaps reconsider https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D100937 (configure: Add --enable-default-semantic-interposition)? Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572018.html I happen a write-up on https://maskray.me/blog/2021-05-09-fno-semantic-interposition --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF