From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7904 invoked by alias); 6 Oct 2011 15:55:04 -0000 Received: (qmail 7858 invoked by uid 22791); 6 Oct 2011 15:55:01 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Oct 2011 15:54:46 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p96FsjrT020963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Oct 2011 11:54:45 -0400 Received: from anchor.twiddle.net (vpn-236-148.phx2.redhat.com [10.3.236.148]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p96Fsiej025406; Thu, 6 Oct 2011 11:54:45 -0400 Message-ID: <4E8DCF44.2050808@redhat.com> Date: Thu, 06 Oct 2011 21:09:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: David Miller CC: dbremner@gmail.com, "gcc@gcc.gnu.org" Subject: Re: float "op-and-halve" References: <20110930.195241.594176032826497882.davem@davemloft.net> <20111005.221651.1897422273355993040.davem@davemloft.net> In-Reply-To: <20111005.221651.1897422273355993040.davem@davemloft.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00093.txt.bz2 On 10/05/2011 07:16 PM, David Miller wrote: > From: David Bremner > Date: Wed, 5 Oct 2011 19:08:41 -0700 > >> What about treating these instructions as fused multiply-adds with >> constant arguments? > > Richard Henderson (CC:'d) chatted with me the other day about this and > made the same initial suggestion, but after thinking about it some > more he concluded that this would not work currently. > >> The reciprocal of 2 is exactly represented, so there's no loss of >> precision. The x86 backend uses a similar method to model the x87 >> instructions that load various constants, see >> standard_80387_constant_p. > > Indeed, it sounds compelling. > > Richard, what was the exact reason doing this won't work? I don't > quite remember the details. We were talking about a representation of (fma (plus a b) 0.5 -0.0) Problems with this arise when the compiler propagates constants into both A and B and tries to fold this. The PLUS will be simplified independently of the FMA. Which means that the compiler evaluation of the expression will see overflow when the insn won't. We'd have to invent a new "fp-add-and-multiply" rtx code taking two addition operands and a multiplication operand in order to get the compiler to fold this properly. Which doesn't seem that worthwhile given that Sparc is the only target I've seen with this feature. OTOH, we do have the target hook whereby we can simplify the builtin during gimple optimization. And unless our gimple optimizers are totally falling over should take care of all of the folding possibilities. You'd need to use the MPFR routines to properly evaluate this, Dave. r~