From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77688 invoked by alias); 15 Sep 2016 15:52:38 -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 77664 invoked by uid 89); 15 Sep 2016 15:52:38 -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_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Sep 2016 15:52:37 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7212DA0C5C; Thu, 15 Sep 2016 15:52:35 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-2.phx2.redhat.com [10.3.116.2]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8FFqYMZ010100; Thu, 15 Sep 2016 11:52:34 -0400 Subject: Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible To: Richard Biener References: <20160913084133.GE7282@tucnak.redhat.com> <29751c79-6a6b-a597-7025-eea32b63ba0f@redhat.com> Cc: Jakub Jelinek , Tamar Christina , GCC Patches , "rguenther@suse.de" , nd From: Jeff Law Message-ID: <134f0dc5-f4ed-c5a3-d89f-6d79ba9d93f6@redhat.com> Date: Thu, 15 Sep 2016 16:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00959.txt.bz2 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. > > Not something that should block this patch though. Agreed. jeff