From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50545 invoked by alias); 17 Aug 2019 08:21:08 -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 50535 invoked by uid 89); 17 Aug 2019 08:21:07 -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=H*f:sk:mpto90p, H*i:sk:CACMrGj, fold_rtx, cse_insn 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; Sat, 17 Aug 2019 08:21:05 +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 0A784344; Sat, 17 Aug 2019 01:21:03 -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 183413F718; Sat, 17 Aug 2019 01:21:01 -0700 (PDT) From: Richard Sandiford To: Tejas Joshi Mail-Followup-To: Tejas Joshi ,gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, segher@kernel.crashing.org, joseph@codesourcery.com, richard.sandiford@arm.com Cc: gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, segher@kernel.crashing.org, 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: Sat, 17 Aug 2019 08:21:00 -0000 In-Reply-To: (Tejas Joshi's message of "Sat, 17 Aug 2019 11:16:54 +0530") 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/msg00126.txt.bz2 Tejas Joshi writes: > Hi, > >> It's just a different name, nothing more, nothing less. Because it is >> a different name it can not be accidentally generated from actual >> truncations. > > I have introduced float_narrow but I could not find appropriate places > to generate it for a call to fadd instead it to generate a CALL. I > used GDB to set breakpoints which hit fold_rtx and cse_insn but I got > confused with the rtx codes and passes which generate respective RTL. > It should not be similar to FLOAT_TRUNCATE if we want to avoid it > generating for actual truncations? Please don't do it this way. The whole point of the work is that this is a single operation that cannot be modelled as a post-processing of a normal double addition result. It's a single operation at the source level, a single IFN, a single optab, and a single instruction. Splitting it apart into two operations for rtl only, and making it look in rtl terms like a post-processing of a normal addition result, seems like it's going to come back to bite us. In lisp terms we're saying that the operand to the float_narrow is implicitly quoted: (float_narrow:m '(plus:n a b)) so that when float_narrow is evaluated, the argument is the unevaluated rtl expression "(plus a b)" rather than the evaluated result a + b. float_narrow then does its own evaluation of a and b and performs a fused addition and narrowing on the result. No other rtx rvalue works like this. rtx nappings like simplification or evaluation are normally depth-first, so that the mapping is applied to the operands first, and then the root is mapped/simplified/evaluated with the results. Adding implicit lisp quoting would require special cases in these routines for float_narrow. The only current analogue I can think of for this is the handling of zero_extend on const_ints. Because const_ints are modeless, we have to avoid cases in which the recursion produces things like: (zero_extend:m (const_int -1)) because it's no longer clear what mode the zero_extend is extending from. But I think that's seen as a wart of having modeless const_ints. I don't think it's something we should actively embrace by adding float_narrow. Using float_narrow would also be inconsistent with the way we handle saturating arithmetic. There we use US_PLUS and SS_PLUS rtx codes for unsigned and signed saturating plus respectively, rather than: (unsigned_sat '(plus a b)) (signed_sat '(plus a b)) Using dedicated codes might seem clunky. But it's simple, safe, and fits the existing model without special cases. :-) Thanks, Richard > > Thanks, > Tejas > > > On Fri, 16 Aug 2019 at 15:53, Richard Sandiford > wrote: >> >> 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