From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123060 invoked by alias); 17 Aug 2019 05:40:47 -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 123050 invoked by uid 89); 17 Aug 2019 05:40:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.6 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=H*f:sk:mpto90p, H*i:sk:mpto90p 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; Sat, 17 Aug 2019 05:40:45 +0000 Received: by mail-ed1-f51.google.com with SMTP id g8so6851131edm.6 for ; Fri, 16 Aug 2019 22:40:44 -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=4IE1XEidwxhSgaj8mooH47lF0Su33lpNfLKokzJnWV4=; b=RZGfvqTj7NkLN8/roTXVgxhTxpAkDPZf3h8pj6V2q84BW1Hm72Kuq0DLEoeNO6cfqS UPZ7FNuBIgW8oo7bjdeJNvrNIeOrF1HnKwwR85Gac1llDdSp9D2jkEL7Uc8GGMiEOYpf dgG6LzEujw2NkSoRatRsVHhEwq8efyMsnEyvvIbkMs6kXNjMmYyScCn9Zst/Je+xlO55 /0BAmwC7c+/ejebKjy28W/748f/ZCGbp337VujuyVd86CMCkNMkUdTq1p8f/cKUX520U t2MEaP55V32mK2VtJQwi+IUsviK21lOWh00dqL5KB1cAEgxcEoPP/o/p4DAOs6FFccP0 7aIA== MIME-Version: 1.0 References: <20190812215224.GC31406@gate.crashing.org> <20190814072127.GE31406@gate.crashing.org> <20190814202102.GI31406@gate.crashing.org> <20190814210015.GJ31406@gate.crashing.org> <20190815184450.GO31406@gate.crashing.org> In-Reply-To: From: Tejas Joshi Date: Sat, 17 Aug 2019 05:40: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/msg00125.txt.bz2 Hi, > It's just a different name, nothing more, nothing less. Because it is > a different name it can not be accidentally generated from actual > truncations. I have introduced float_narrow but I could not find appropriate places to generate it for a call to fadd instead it to generate a CALL. I used GDB to set breakpoints which hit fold_rtx and cse_insn but I got confused with the rtx codes and passes which generate respective RTL. It should not be similar to FLOAT_TRUNCATE if we want to avoid it generating for actual truncations? Thanks, Tejas On Fri, 16 Aug 2019 at 15:53, Richard Sandiford wrote: > > Segher Boessenkool writes: > > 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. > > But a PLUS should behave as a PLUS in any context. Making its > behaviour dependent on the containing rtxes (if any) would be a > can of worms. > > Richard