From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81248 invoked by alias); 16 Aug 2019 10:23:41 -0000 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 Received: (qmail 81237 invoked by uid 89); 16 Aug 2019 10:23:41 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=rtxes X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Aug 2019 10:23:39 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D841C28; Fri, 16 Aug 2019 03:23:37 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E6C683F706; Fri, 16 Aug 2019 03:23:36 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com, richard.sandiford@arm.com Cc: Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com Subject: Re: Expansion of narrowing math built-ins into power instructions References: <20190812215224.GC31406@gate.crashing.org> <20190814072127.GE31406@gate.crashing.org> <20190814202102.GI31406@gate.crashing.org> <20190814210015.GJ31406@gate.crashing.org> <20190815184450.GO31406@gate.crashing.org> Date: Fri, 16 Aug 2019 10:23:00 -0000 In-Reply-To: <20190815184450.GO31406@gate.crashing.org> (Segher Boessenkool's message of "Thu, 15 Aug 2019 13:44:50 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00120.txt.bz2 Segher Boessenkool writes: > On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote: >> Tejas Joshi writes: >> > Hello. >> > I just wanted to make sure that I am looking at the correct code here. >> > Except for rtl.def where I should be introducing something like >> > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints > > I like that "float_narrow" name :-) > >> > set on functions around expr.c, cfgexpand.c where I grep for >> > float_truncate/FLOAT_TRUNCATE did not hit. >> > Also, in what manner should float_contract/narrow be different from >> > float_truncate as both are trying to do similar things? (truncation >> > from DF to SF) >> >> I think the code should instead be a fused addition and truncation, >> a bit like FMA is a fused addition and multiplication. Describing it as >> a DFmode addition followed by some conversion to SF would still involve >> double rounding. > > How so? It would *mean* there is only single rounding, even! That's > the whole point of it. But a PLUS should behave as a PLUS in any context. Making its behaviour dependent on the containing rtxes (if any) would be a can of worms. Richard