From patchwork Wed Apr 25 13:58:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Marc Glisse X-Patchwork-Id: 154930 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 49A2AB6EE7 for ; Wed, 25 Apr 2012 23:59:08 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1335967148; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Date: From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=4n9/Kq6vsam4dLK1JAcprHu1qT4=; b=Uoll4tuM6E2bhHW 4CD3wmrJ2hkw/Ey9D0UQ6na7YQlbVfbKiKredQvbXwsfyAn5O1YDwIezgAZWsb6O +PL5PeRWM29yba/kvzXFKlWWGRCrIyKi5aidiOVOXuWTVbnZyjPUTkkqVW9zFm3T tcCue8zCjpwYh8YueFxl23NUSAa0= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=E+TWi0lSe2Mu8pA9zF5VNQvwU+FHcI4KYYDGDXEav1Pi4yPatdRhd2lKSAup2L bXaUv1HDcyuGdGObN0HpfPcwVJUoiXgkyVsbUW2DH64P+PPG7o8hvNNp4XNFe6MA wcXQVT+xPZ2E6S/TUnxMqQe1iqo4AGPAspPiTCj5sGn0s=; Received: (qmail 8520 invoked by alias); 25 Apr 2012 13:59:04 -0000 Received: (qmail 8509 invoked by uid 22791); 25 Apr 2012 13:59:02 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_HI, TW_TM, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail1-relais-roc.national.inria.fr (HELO mail1-relais-roc.national.inria.fr) (192.134.164.82) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Apr 2012 13:58:48 +0000 Received: from ip-216.net-81-220-90.toulouse.rev.numericable.fr (HELO laptop-mg.local) ([81.220.90.216]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Apr 2012 15:58:43 +0200 Date: Wed, 25 Apr 2012 15:58:39 +0200 (CEST) From: Marc Glisse To: Richard Guenther cc: gcc-patches@gcc.gnu.org Subject: Re: combine_conversions int->double->int In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Wed, 25 Apr 2012, Richard Guenther wrote: > On Wed, Apr 25, 2012 at 10:12 AM, Marc Glisse wrote: >> Hello, >> >> a conversion like int->double->int is just the identity, as long as double >> is big enough to represent all ints exactly. The most natural way I found to >> do this optimization is the attached: >> >> 2012-04-25  Marc Glisse   >> >>        PR middle-end/27139 >>        * tree-ssa-forwprop.c (combine_conversions): Handle INT->FP->INT. >> >> Does the approach make sense? I don't know that code, and adding FLOAT_EXPR >> / FIX_TRUNC_EXPR was a bit of guesswork. The precision of double could be >> multiplied by log2(base), but not doing it is safe. If the approach is ok, I >> could extend it so int->double->long also skips the intermediate conversion. >> >> Bootstrapped and regression tested on linux-x86_64. >> >> Should I try and write a testcase for a specific target checking for >> specific asm instructions there, or is there a better way? > > Well, scanning the forwprop dump for example. > > Btw, I think not munging this new case into the existing CONVERT_EXPR_P > code would be better - it makes the code (even) harder to understand and > I'm not convinced that adding FLOAT_EXPR/FIX_TRUNC_EXPR handling > does not wreck any assumptions in that code. > > It also seems that for DECIMAL_FLOAT_TYPE_P the transform is always > valid? > > Richard. > >> (note that I can't commit) Here is take 2 on this patch, which seems cleaner. Bootstrapped and regression tested. gcc/ChangeLog 2012-04-25  Marc Glisse   PR middle-end/27139 * tree-ssa-forwprop.c (combine_conversions): Handle INT->FP->INT. gcc/testsuite/ChangeLog 2012-04-25  Marc Glisse   PR middle-end/27139 * gcc.dg/tree-ssa/forwprop-18.c: New test. In my patch, the lines with gimple_assign_* are vaguely guessed from what is around, I don't pretend to understand them. While doing this, I noticed what I think is a mistake in a comment: --- gcc/real.c (revision 186761) +++ gcc/real.c (working copy) @@ -2814,11 +2814,11 @@ significand_size (enum machine_mode mode return 0; if (fmt->b == 10) { /* Return the size in bits of the largest binary value that can be - held by the decimal coefficient for this mode. This is one more + held by the decimal coefficient for this mode. This is one less than the number of bits required to hold the largest coefficient of this mode. */ double log2_10 = 3.3219281; return fmt->p * log2_10; }