From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103246 invoked by alias); 19 Aug 2019 10:46:37 -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 103234 invoked by uid 89); 19 Aug 2019 10:46:36 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=HX-HELO:sk:mail-ed, codes, HX-Received:a50, arise X-HELO: mail-ed1-f44.google.com Received: from mail-ed1-f44.google.com (HELO mail-ed1-f44.google.com) (209.85.208.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 10:46:34 +0000 Received: by mail-ed1-f44.google.com with SMTP id h8so1226336edv.7 for ; Mon, 19 Aug 2019 03:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d1aWXPaMCPuvjpGl1GaRdqO4i3+lJOt6y5NRPVMIHus=; b=m2yulIc3oh9UR1hWcY+J7V8CkDV8L81lB9qrprFNHyU0zKGCTlkVexqiAgzKAhLdQS 1C5oSNes+KzUlDgr08sFdKSvwJSJhYqXjkhSnRAoT5KcOhLI9tGtuzFpu54P01rsimDE e59p5f2mqks03jXr20WVMnSIQzN2DlPKJiAo6YkxR0uMTyG2HerBoZCR+L3W7762ffmO lu39I2Az+rGOxP4UkuDRCrE5nZqMGdGgnAyt6ccknZsvMpaciMV65ae4LNKi5VeGQdfK oUfw/xAy8ddlQlfN3GIvDkzrbqfnG3iBJNCZ2VNClXH7WPM3ZPvxMSSDHSZa0nV9CXHZ vZ4Q== MIME-Version: 1.0 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> In-Reply-To: From: Tejas Joshi Date: Mon, 19 Aug 2019 10:46:00 -0000 Message-ID: Subject: Re: Expansion of narrowing math built-ins into power instructions To: gcc@gcc.gnu.org Cc: Martin Jambor , hubicka@ucw.cz, segher@kernel.crashing.org, joseph@codesourcery.com, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00131.txt.bz2 > but an unspec is of course easiest for now. So, at this point, should I proceed with UNSPEC considering the complications that might arise as Richard points out? On Sat, 17 Aug 2019 at 13:51, Richard Sandiford wrote: > > 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