From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111372 invoked by alias); 14 Sep 2017 16:50:18 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 111351 invoked by uid 89); 14 Sep 2017 16:50:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=tradeoffs, Hx-languages-length:1625, our X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Sep 2017 16:50:16 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id AB063544D63; Thu, 14 Sep 2017 18:50:13 +0200 (CEST) Date: Thu, 14 Sep 2017 16:50:00 -0000 From: Jan Hubicka To: Richard Biener Cc: Joseph Myers , Uros Bizjak , "gcc-patches@gcc.gnu.org" Subject: Re: Add option for whether ceil etc. can raise "inexact", adjust x86 conditions Message-ID: <20170914165013.GA66629@kam.mff.cuni.cz> References: <20160526175950.GA60285@kam.mff.cuni.cz> <20170815135244.4jsd4jyeg6q2lyjc@virgil.suse.cz> <20170913173403.gnvqxx43kbv3ao6n@virgil.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2017-09/txt/msg00918.txt.bz2 > > Well, it's of course the poor-mans solution compared to providing our own > ifunc-enabled libm ... One benefit here would be that we could have our own calling convention for this. So for floor/ceil we may just declare registers to be preserved (as they are on all modern AVX enabled cpus) which would make the code size/speed tradeoffs more interesting. Honza > > I would expect that for SSE 4.1 the PLT and call overhead is measurable > and an inline run-time check be quite a bit more efficient. As you have a > testcase would it be possible to measure that by hand-editing the assembly > (or the benchmark source in case it is not fortran...)? > > The whole point of having the inline expansions was to have inline expansions, > avoding the need to spill the whole set of SSE regs around such calls. > > > I was just surprised by the glibc check, what would you consider a > > recent-enough glibc? Or is the check mainly necessary to ensure we > > are indeed using glibc and not some other libc (and thus something > > like we do for TARGET_LIBC_PROVIDES_SSP would do)? > > > > I will try to come up with a patch. > > I don't think this is the appropriate solution. Try disabling the inline > expansion and run SPEC (without -march=sse4.1 of course). > > I realize that doing the inline-expansion with a runtime check > is going to be quite tricky and the GCC local IFUNC trick doesn't > solve the inlining (but we might be able to avoid spilling with some > IPA RA help and/or attributes?). > > Richard. > > > Thanks, > > > > Martin