From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120335 invoked by alias); 14 Aug 2019 06:15: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 120195 invoked by uid 89); 14 Aug 2019 06:15:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.1 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=fadds, H*f:sk:1HPyEQQ, d,wa, H*f:sk:CvHsufc X-HELO: mail-ed1-f51.google.com Received: from mail-ed1-f51.google.com (HELO mail-ed1-f51.google.com) (209.85.208.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 Aug 2019 06:15:25 +0000 Received: by mail-ed1-f51.google.com with SMTP id f22so6059099edt.4 for ; Tue, 13 Aug 2019 23:15:21 -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=35agyC5gXVsTYRGwRA+Qvmgd5WFgH1sB1K9SKmbA7x4=; b=LAAMoPet9N8T9E5N4f/DjaxKyzdtJwapqiOMFjSOIC660fePYh0CZQMxW7ha5q9eQ1 eb4mjVFU88tWU+5q/XdTOq1OiR9wi+/cy7v+4W3kxwFNpQCtOE9J1fMMr4LrC5q6Xoxv lndA76/dUKU82u+qcdOdKiUCXO03xgnsGGMn7rZvsqX6Ly8WkEcGhz/oIXoJpZDF+s8y PMhXCUi6hoOiVshmUfwjeGC5S7FxpzSHsCNRk4ttTKHKBaPYLRDXvl34um+mOy3OBudT I6kqNgTX74R8t6P8gB4BCU0RMEkl6rxV9S24v+CD7/7og9KLwqFTWuJJcF9qzDznHiG2 DCOA== MIME-Version: 1.0 References: <20190731144722.GS31406@gate.crashing.org> <20190808200514.GL31406@gate.crashing.org> <20190811165916.GX31406@gate.crashing.org> <20190812175450.GB31406@gate.crashing.org> <20190812215224.GC31406@gate.crashing.org> In-Reply-To: <20190812215224.GC31406@gate.crashing.org> From: Tejas Joshi Date: Wed, 14 Aug 2019 06:15: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 Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00099.txt.bz2 > The RTL needs to be something that > does *not* match the combination of separate operations (just as fma has > its own RTL, and a separate pass is responsible for converting separate So do I need to introduce fadd's own RTL just as fma which would emit a fused instruction while -ffp-contract is default (fast) and would emit separate instructions like add in DFmode and then truncate to SF? while -ffp-contract=off ? (just as fma) On Tue, 13 Aug 2019 at 03:22, Segher Boessenkool wrote: > > On Mon, Aug 12, 2019 at 09:20:18PM +0000, Joseph Myers wrote: > > On Mon, 12 Aug 2019, Segher Boessenkool wrote: > > > > > (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"))))] > > > > That sort of pattern is incorrect for a fused operation such as fadd, > > because combine could match it for code that is supposed to do separate > > addition and narrowing conversion. The RTL needs to be something that > > does *not* match the combination of separate operations (just as fma has > > its own RTL, and a separate pass is responsible for converting separate > > operations to fused ones in the -ffp-contract=fast case where it's > > permitted). > > Ugh, we allow disabling contraction, I forgot. Rats. > > > Segher