From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77981 invoked by alias); 12 Aug 2019 17:55:00 -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 77973 invoked by uid 89); 12 Aug 2019 17:54:59 -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=fwa, optab, $a$b, add_truncba3 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, 12 Aug 2019 17:54:57 +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 x7CHspcO001967; Mon, 12 Aug 2019 12:54:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7CHsoTB001964; Mon, 12 Aug 2019 12:54:50 -0500 Date: Mon, 12 Aug 2019 17:55: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: <20190812175450.GB31406@gate.crashing.org> References: <87sgqnx4i6.fsf@oldenburg2.str.redhat.com> <20190731144722.GS31406@gate.crashing.org> <20190808200514.GL31406@gate.crashing.org> <20190811165916.GX31406@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/msg00096.txt.bz2 On Mon, Aug 12, 2019 at 11:01:11PM +0530, Tejas Joshi wrote: > I have the following code in my rs6000.md (I haven't used new TARGET_* yet) : > > (define_expand "add_truncdfsf3" > [(set (match_operand:SF 0 "gpc_reg_operand") > (float_truncate:SF > (plus:DF (match_operand:DF 1 "gpc_reg_operand") > (match_operand:DF 2 "gpc_reg_operand"))))] > "TARGET_HARD_FLOAT" > "") > > (define_insn "*add_truncdfsf3_fpr" > [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa") > (float_truncate:SF > (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa") > (match_operand:DF 2 "gpc_reg_operand" "d,wa"))))] > "TARGET_HARD_FLOAT" > "@ > fadds %0,%1,%2 > xsaddsp %x0,%x1,%x2" > [(set_attr "type" "fp")]) Those look fine. You can also merge them into one: (define_insn "add_truncdfsf3" [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa") (float_truncate:SF (plus:DF (match_operand:DF 1 "gpc_reg_operand" "%d,wa") (match_operand:DF 2 "gpc_reg_operand" "d,wa"))))] "TARGET_HARD_FLOAT" "@ fadds %0,%1,%2 xsaddsp %x0,%x1,%x2" [(set_attr "type" "fp")]) > with following optab in optabs.def : > > OPTAB_CD(fadd_optab, "add_trunc$b$a3") (what is the > difference between $b$a and $a$b?) Which of the two modes becomes $a and which becomes $b? It depends on the definition of fadd_optab what order is expected, I think. Segher