From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62125 invoked by alias); 14 Sep 2016 08:24:57 -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 62112 invoked by uid 89); 14 Sep 2016 08:24:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy=our X-HELO: mail-wm0-f65.google.com Received: from mail-wm0-f65.google.com (HELO mail-wm0-f65.google.com) (74.125.82.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Sep 2016 08:24:55 +0000 Received: by mail-wm0-f65.google.com with SMTP id b187so1362803wme.0 for ; Wed, 14 Sep 2016 01:24:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9XZtLtA9xlOd0iNP7jhLlNxnjacKJPzX2j+QA4vEaf0=; b=bikQbo40BQe8YtQbQ4hR+dqzAtkPDQSB93fEgAPmpn7HEXOsSxT1QIZ7IwPoyaEc0x ynFprPjsxZmu+FNJdpKbArTsNCjWWEC++X+nxtKTYX3hWTOvybH1WmHPslSJwMVvxJNE 84vOUnwrOcmp64yf7egtbVYWD/Sg/8gBOd4A6Cm8UBKycJz9oNtxMdYmQFuD6sCxQ/xC zuZ2ZyC35urcz+wCGZ5QM955wxrbTM5h9MPF3iReRtBqe+PawyrrY0LXN6049ZHpeZpC /8/BT2H+sfODSf3007/xHlCtTGOP3dV4zJDebyHkkPSw9n63slocIeEVqE5tpMTv/kNo BeUQ== X-Gm-Message-State: AE9vXwP7Pf+FUBzfOoMEW6L+6SSw+28ml0Fyv+Zin/6SAOawUIwdrnffR0wiCHeye/8f/mMWGs4n56pek/TQdQ== X-Received: by 10.194.172.42 with SMTP id az10mr1304159wjc.178.1473841493074; Wed, 14 Sep 2016 01:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.129 with HTTP; Wed, 14 Sep 2016 01:24:52 -0700 (PDT) In-Reply-To: <29751c79-6a6b-a597-7025-eea32b63ba0f@redhat.com> References: <20160913084133.GE7282@tucnak.redhat.com> <29751c79-6a6b-a597-7025-eea32b63ba0f@redhat.com> From: Richard Biener Date: Wed, 14 Sep 2016 08:31:00 -0000 Message-ID: Subject: Re: [PATCH] Optimise the fpclassify builtin to perform integer operations when possible To: Jeff Law Cc: Jakub Jelinek , Tamar Christina , GCC Patches , "rguenther@suse.de" , nd Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00787.txt.bz2 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. The only reason to not use integer operation (compared to what fold_builtin_classify does currently) is that the folding is done very early at the moment and it's harder to optimize the integer bit-twiddling with more FP context known. Like if we know if (! isnan ()) then unless we also expand that inline via bit-twiddling nothing will optimize the followup test from the fpclassify. This might be somewhat moot at the moment given our lack of FP value-range propagation but it should be a general concern (of doing this too early). 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 something that should block this patch though. Richard. > jeff