From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 0BC633858014 for ; Fri, 19 Nov 2021 17:55:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0BC633858014 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id DB77F1FD32; Fri, 19 Nov 2021 17:55:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1637344531; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kRP3sZ30ciwQWrIFqma/ZktgEGhOZHFbI/fb/ufNfg8=; b=O73UKrQg1AS8lin4qJqYiveeqY966iGqS/A/cqjqPmXpC1emxJyhDxwW3tG8mtRBXxXLRq O2TAv1kB4pHSUiRW0rfq9mSzN85khwEgxvAOVabX3MSYFBIZgrl90VBL6tK61/iRjCUypV hpcHj4jLGU1FReUJN0QVShUT1Fx1f0Q= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1637344531; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kRP3sZ30ciwQWrIFqma/ZktgEGhOZHFbI/fb/ufNfg8=; b=s5zy3bQmtKVJu3tTHr2Siv5a1yUc5bo+2ThrY0UxW94xfG5yOr9ziWNST++RpPZ5Sk4Pdb Asi+xbxAqzw0WdBA== Received: from suse.cz (virgil.suse.cz [10.100.13.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C8426A3B83; Fri, 19 Nov 2021 17:55:31 +0000 (UTC) From: Martin Jambor To: Jan Hubicka Cc: GCC Patches Subject: Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition In-Reply-To: <20211119115101.GA57358@kam.mff.cuni.cz> References: <20211118173123.GC76860@kam.mff.cuni.cz> <20211119115101.GA57358@kam.mff.cuni.cz> User-Agent: Notmuch/0.34.1 (https://notmuchmail.org) Emacs/27.2 (x86_64-suse-linux-gnu) Date: Fri, 19 Nov 2021 18:55:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 19 Nov 2021 17:55:34 -0000 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 people >> > > to bring about considerable speed up at the cost of strict compliance >> > > to the ELF symbol interposition rules See for example >> > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup >> > > >> > > As such I believe it should be implied by our -Ofast optimization >> > > level, not only so that benchmarks that can benefit run faster, but >> > > also so that people looking at -Ofast documentation for options that >> > > 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 bootstrapping >> > > 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 wwwdocs >> > > after I commit the patch.) >> > > >> > >> > Unfortunately, I was wrong, there are testcases which use the optimize >> > 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 only >> > had a quick glance at the results). >> > >> > I am not sure what is the right way to tackle this, whether to set the >> > flag at Ofast in some nonstandard way or make the flag an optimization >> > flag - probably affecting function definitions, having it affect >> > call-sites seems too fine-grained. I will try to discuss this on IRC 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 adding >> 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 program. >> 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-testing. Martin