From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199908-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12441 invoked by alias); 14 Aug 2019 20:21:10 -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 12433 invoked by uid 89); 14 Aug 2019 20:21:10 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=
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; Wed, 14 Aug 2019 20:21:08 +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 x7EKL36B012633;	Wed, 14 Aug 2019 15:21:04 -0500
Received: (from segher@localhost)	by gate.crashing.org (8.14.1/8.14.1/Submit) id x7EKL23V012632;	Wed, 14 Aug 2019 15:21:02 -0500
Date: Wed, 14 Aug 2019 20:21:00 -0000
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Joseph Myers <joseph@codesourcery.com>
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
Message-ID: <20190814202102.GI31406@gate.crashing.org>
References: <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> <alpine.DEB.2.21.1908122118140.18203@digraph.polyomino.org.uk> <20190812215224.GC31406@gate.crashing.org> <CACMrGjDbF8qyaF8_p5ofOT7gFRqMyOTtzxsKRM3r2aXX+8KS+A@mail.gmail.com> <20190814072127.GE31406@gate.crashing.org> <alpine.DEB.2.21.1908141608430.14831@digraph.polyomino.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.1908141608430.14831@digraph.polyomino.org.uk>
User-Agent: Mutt/1.4.2.3i
X-IsSubscribed: yes
X-SW-Source: 2019-08/txt/msg00102.txt.bz2

On Wed, Aug 14, 2019 at 04:10:56PM +0000, Joseph Myers wrote:
> On Wed, 14 Aug 2019, Segher Boessenkool wrote:
> 
> > I think you can do one RTL code that replaces float_truncate in
> > 
> > > > > > (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"))))]
> > 
> > but that is only meant for such explicit contraction.  This can then
> > happily be used to implement all such patterns.  Is there some issue
> > with that I overlook?
> 
> Yes, I think such a separate RTL code would work (as would an 
> architecture-specific UNSPEC) - it just needs to avoid the pattern 
> matching RTL that can arise other than from the built-in functions.
> 
> (Everything to do with needing -fno-math-errno to expand into such 
> instructions should be handled in the architecture-independent compiler.)

Does something like
  float d; double a, b, x;
  ...
  d = fadd (a + x, b - x);
work as wanted, with such a representation?  It would simplify (does it?) to
  d = fadd (a, b);
but is that allowed?


Segher