From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65581 invoked by alias); 15 Sep 2016 16:20:37 -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 65558 invoked by uid 89); 15 Sep 2016 16:20:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Sep 2016 16:20:35 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id ED363AC0F; Thu, 15 Sep 2016 16:20:32 +0000 (UTC) User-Agent: K-9 Mail for Android In-Reply-To: <134f0dc5-f4ed-c5a3-d89f-6d79ba9d93f6@redhat.com> References: <20160913084133.GE7282@tucnak.redhat.com> <29751c79-6a6b-a597-7025-eea32b63ba0f@redhat.com> <134f0dc5-f4ed-c5a3-d89f-6d79ba9d93f6@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible From: Richard Biener Date: Thu, 15 Sep 2016 16:28:00 -0000 To: Jeff Law ,Richard Biener CC: Jakub Jelinek ,Tamar Christina ,GCC Patches ,nd Message-ID: <276B558D-BB1D-4C0B-9E91-8717162B75D6@suse.de> X-SW-Source: 2016-09/txt/msg00962.txt.bz2 On September 15, 2016 5:52:34 PM GMT+02:00, Jeff Law wrote: >On 09/14/2016 02:24 AM, Richard Biener wrote: >> On Tue, Sep 13, 2016 at 6:15 PM, Jeff Law wrote: >>> On 09/13/2016 02:41 AM, Jakub Jelinek wrote: >>>> >>>> On Mon, Sep 12, 2016 at 04:19:32PM +0000, Tamar Christina wrote: >>>>> >>>>> This patch adds an optimized route to the fpclassify builtin >>>>> for floating point numbers which are similar to IEEE-754 in >format. >>>>> >>>>> The goal is to make it faster by: >>>>> 1. Trying to determine the most common case first >>>>> (e.g. the float is a Normal number) and then the >>>>> rest. The amount of code generated at -O2 are >>>>> about the same +/- 1 instruction, but the code >>>>> is much better. >>>>> 2. Using integer operation in the optimized path. >>>> >>>> >>>> Is it generally preferable to use integer operations for this >instead >>>> of floating point operations? I mean various targets have quite >high >>>> costs >>>> of moving data in between the general purpose and floating point >register >>>> file, often it has to go through memory etc. >>> >>> Bit testing/twiddling is obviously a trade-off for a non-addressable >object. >>> I don't think there's any reasonable way to always generate the most >>> efficient code as it's going to depend on (for example) register >allocation >>> behavior. >>> >>> So what we're stuck doing is relying on the target costing bits to >guide >>> this kind of thing. >> >> I think the reason for this patch is to provide a general optimized >> integer version. >And just to be clear, that's fine with me. While there are cases where > >bit twiddling hurts, I think bit twiddling is generally better. > > >> I think it asks for a FP (class) propagation pass somewhere (maybe as >part of >> complex lowering which already has a similar "coarse" lattice -- not >that I like >> its implementation very much) and doing the "lowering" there. >Not a bad idea -- I wonder how much a coarse tracking of the >exceptional >cases would allow later optimization. I guess it really depends on the ability to set ffast-math flags on individual stmts (or at least built-in calls). Richard. >> >> Not something that should block this patch though. >Agreed. > >jeff