From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59092 invoked by alias); 15 Aug 2019 18:45:01 -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 59084 invoked by uid 89); 15 Aug 2019 18:45:00 -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=H*f:sk:mpta7ca, H*i:sk:mpta7ca 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; Thu, 15 Aug 2019 18:44:59 +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 x7FIiqLR004304; Thu, 15 Aug 2019 13:44:52 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7FIipAt004303; Thu, 15 Aug 2019 13:44:51 -0500 Date: Thu, 15 Aug 2019 18:45:00 -0000 From: Segher Boessenkool To: Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com, richard.sandiford@arm.com Subject: Re: Expansion of narrowing math built-ins into power instructions Message-ID: <20190815184450.GO31406@gate.crashing.org> References: <20190812215224.GC31406@gate.crashing.org> <20190814072127.GE31406@gate.crashing.org> <20190814202102.GI31406@gate.crashing.org> <20190814210015.GJ31406@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/msg00115.txt.bz2 On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote: > Tejas Joshi writes: > > Hello. > > I just wanted to make sure that I am looking at the correct code here. > > Except for rtl.def where I should be introducing something like > > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints I like that "float_narrow" name :-) > > set on functions around expr.c, cfgexpand.c where I grep for > > float_truncate/FLOAT_TRUNCATE did not hit. > > Also, in what manner should float_contract/narrow be different from > > float_truncate as both are trying to do similar things? (truncation > > from DF to SF) > > I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding. How so? It would *mean* there is only single rounding, even! That's the whole point of it. > simplify-rtx.c is probably the most important place to handle it. > It would be easiest to test using the selftests at the end of the file. Segher