From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33006 invoked by alias); 19 Aug 2019 13:07:32 -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 32992 invoked by uid 89); 19 Aug 2019 13:07:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=codes, Tejas, H*f:sk:CACMrGj, tejas X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 19 Aug 2019 13:07:31 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x7JD7Lie017229; Mon, 19 Aug 2019 08:07:22 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7JD7KSu017225; Mon, 19 Aug 2019 08:07:20 -0500 Date: Mon, 19 Aug 2019 13:07:00 -0000 From: Segher Boessenkool To: Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com, richard.sandiford@arm.com Subject: Re: Expansion of narrowing math built-ins into power instructions Message-ID: <20190819130720.GG31406@gate.crashing.org> References: <20190814202102.GI31406@gate.crashing.org> <20190814210015.GJ31406@gate.crashing.org> <20190815184450.GO31406@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00134.txt.bz2 Hi Richard, On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote: > Tejas Joshi writes: > >> 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. RTL isn't Lisp. RTL doesn't have quotations. RTL doesn't have *evaluation*. RTL is just a data structure that describes your program instructions. A large part of what means what is system-specific. Rounding of floating point is not defined, for example. And yes, various parts of GCC can manipulate RTL, doing substitution and algebraic simplication and whatnot. All within the rules of RTL. And that means nothing ever can "pass" a float_narrow, because there are no rules that allow it to. > No other rtx rvalue works like this. A lot of unspecs are used like this, for example. > 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. :-) And you need many many more RTX codes, which you will not handle in almost all places, because there are too many. I agree this construct is not as nice as could be hoped for. I don't agree that 60 new RTX codes is an acceptable solution (or that that will ever really work out, even). It would be nice if somehow we could make a variant of RTL codes, so that we could have nice and simple code that applies to all variants of some code. Not sure how that would work out. Maybe we don't have to do this very generically, how often will we need this anyway? I have three examples so far: 1) Saturating arithmetic; 2) This float_narrow thing; 3) Ordered compares, that is, fp compares that set an exception on NaNs. Something that works for all three would be nice! Segher