From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116521 invoked by alias); 26 Aug 2019 07:42:19 -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 116217 invoked by uid 89); 26 Aug 2019 07:42:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_05,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=fd, H*f:sk:ri6h867, ieee128, H*f:sk:CACMrGj 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, 26 Aug 2019 07:42:17 +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 x7Q7gCBt023347; Mon, 26 Aug 2019 02:42:13 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7Q7gBi0023345; Mon, 26 Aug 2019 02:42:11 -0500 Date: Mon, 26 Aug 2019 07:42:00 -0000 From: Segher Boessenkool To: Tejas Joshi Cc: gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com Subject: Re: Expansion of narrowing math built-ins into power instructions Message-ID: <20190826074211.GQ31406@gate.crashing.org> References: <20190821191722.GH31406@gate.crashing.org> <20190822062503.GI31406@gate.crashing.org> <20190822095620.GK31406@gate.crashing.org> <20190825164717.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/msg00215.txt.bz2 > > [ Please don't top-post ] On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote: > Sorry for not being clear. I am confused about some modes here. I > meant, just as we expanded fadd (which narrows down from double to > float) with add_truncdfsf3, how can I expand faddl (which narrows down > long double to float). Wouldn't I require TFmode -> SFmode as > add_trunctfsf3 just as Joseph had previously mentioned? Yes, you need an addsfkf2 as well as adddfkf2 (and tf variants of those, there are iterators for that). KF is IEEE QP float. TF is whatever long double maps to, IEEE QP or double-double. > And if yes, > the operand constraints would still be f,d and d for TF->SF or what? SF is "f". KF does not fit in "d". You won't need constraints anyway. There already is add3_odd and you can just use that, in a new defione_expand you make. For example, for DP you need two insns: xsaddqpo followed by xscvqpdp. The second of those is the existing insn pattern truncdf2_hw, so you just get something like (define_expand "adddfkf2" [(set (match_operand:DF 0 "gpc_reg_operand") (unspec:DF [(match_operand:IEEE128 1 "gpc_reg_operand") (match_operand:IEEE128 2 "gpc_reg_operand")] UNSPEC_DUNNO_MENTION_DF_SOMEHOW))] "TARGET_FLOAT128_HW && FLOAT128_IEEE_P (mode)" { rtx tmp = gen_reg_rtx (mode); emit_insn (gen_add3_odd (tmp, operands[1])))), operands[2]); emit_insn (truncdf2_hw (operands[0], tmp)); DONE; }) (not tested at all, be careful :-) ) > Also, just as we generated fadds/xsaddsp instructions for fadd, would > I be generating the same ones for faddl and fadd/xsadddp for daddl > (long double to double) or something different? all for ISA 2.07. (for > ISA 3.0, I might use IEEE128/FLOAT128 round-to-odd instructions like > add_odd followed by conversion to narrower?) For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware that is. I don't know if we'll want fadd support in the emulation libraries ever; don't worry about it for now, anyway. "long double is double" you should probably handle in generic code. "long double is double-double", well, fadd cannot really be done better than an add followed by a conversion in that case? Which boils down to truncating the inputs to double, and then doing whatever you would do for IEEE DP float. Segher