From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199903-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15878 invoked by alias); 12 Aug 2019 21:20:27 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 15869 invoked by uid 89); 12 Aug 2019 21:20:26 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=
X-HELO: esa4.mentor.iphmx.com
Received: from esa4.mentor.iphmx.com (HELO esa4.mentor.iphmx.com) (68.232.137.252) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Aug 2019 21:20:25 +0000
IronPort-SDR: IVSZztNbOkvgzMgw4tMA75XoCvAgbdhHwSFeVBSMP9CxruOS0oDb+OssPUdZc4puC/2BKrcFwy HLcsRYUw4opaAxEcz2+923QjZlHcNzaqlIRpg4eV4ybumNrHgQmsIazP8ap9Ct0GnXQRafsuDb 1PAtXFjI2DZ3FpexqRttp3aWaqdkpyt/KRn+gkXthdCAtEakos5B/gUn00hKx8xOThFIxymAc2 K7U1ZcGBa6RehREM41iV+2vP7L9J+uHwmKyXs2BW94vGug1vqjSJ5ECvht8VScvDgI4IECRBvQ lGc=
Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165])  by esa4.mentor.iphmx.com with ESMTP; 12 Aug 2019 13:20:24 -0800
IronPort-SDR: jib2a8APHYuWn1kZ5TG/NNH6kYz1FxMIhmkw6jdpgm8c9lZo7/yCqt3j0HKyc9HW+RmyN9YQ64 hyXBhq7jcq1imcKdk+t04Gme5QJNKpKERqO7SIchbyhOuefSLdtcJv0eA7cIoAECtUnYcVIaaD xvBqIK4JeOvZE6ju0EkcOd6XwhADGBl/sE28NplhHQF1I+msdhi+eQ3ytfVCZE5NI9kmzA34Hr 4k3jloSYAwktEt4quO1aAT475QPFdVkiUwlhrThPpRYk4PQq5sLXCM/KsHc1fAbfhwq3lC7ghc k5o=
Date: Mon, 12 Aug 2019 21:20:00 -0000
From: Joseph Myers <joseph@codesourcery.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
CC: Tejas Joshi <tejasjoshi9673@gmail.com>, <gcc@gcc.gnu.org>, Martin Jambor	<mjambor@suse.cz>, <hubicka@ucw.cz>
Subject: Re: Expansion of narrowing math built-ins into power instructions
In-Reply-To: <20190812175450.GB31406@gate.crashing.org>
Message-ID: <alpine.DEB.2.21.1908122118140.18203@digraph.polyomino.org.uk>
References: <87sgqnx4i6.fsf@oldenburg2.str.redhat.com> <alpine.DEB.2.21.1907301947090.10734@digraph.polyomino.org.uk> <CACMrGjBiEMp7jj=b30MQ-8SMYoPA_4BFTdQRQSbV7WkYmv+Opg@mail.gmail.com> <20190731144722.GS31406@gate.crashing.org> <CACMrGjC5T-BNowawG9WiKi-C6FRMrtNKnkUSsn1TVT3iFN-Zdg@mail.gmail.com> <20190808200514.GL31406@gate.crashing.org> <alpine.DEB.2.21.1908082304570.5719@digraph.polyomino.org.uk> <CACMrGjB1UmfKuTCwGLi5oTapr4EM-JxbfVGr_GvwucWwfg0oYg@mail.gmail.com> <20190811165916.GX31406@gate.crashing.org> <CACMrGjAPa21OJ_ry+1HPyEQQbZhGOkQTVXwe=CvHsufc_ms_CQ@mail.gmail.com> <20190812175450.GB31406@gate.crashing.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Return-Path: joseph@codesourcery.com
X-SW-Source: 2019-08/txt/msg00097.txt.bz2

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).

-- 
Joseph S. Myers
joseph@codesourcery.com