From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87502 invoked by alias); 15 Aug 2019 13:55:23 -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 87133 invoked by uid 89); 15 Aug 2019 13:55:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.8 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*i:sk:mpta7ca, H*f:sk:mpta7ca, HX-Received:906 X-HELO: mail-ed1-f48.google.com Received: from mail-ed1-f48.google.com (HELO mail-ed1-f48.google.com) (209.85.208.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 13:55:21 +0000 Received: by mail-ed1-f48.google.com with SMTP id p28so2186692edi.3 for ; Thu, 15 Aug 2019 06:55:20 -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=MXsAThwNEk4kW4sgWA5Kd/T3Cr8mwuOxeuQfaMcrAHo=; b=Vb79n8f4ZhB9IJ8+ub2DZumbanEXhe0nqeXPCO/7y7Zar5kFRqkFMpNppG6A+z3E/F r8h7HIQCVg5H0uJ4z2HSB7hT9MTrJZe3LTqyNpLsQ8scVggRDWT1hWswEqrcIDxdARR4 ygYYiARr4fyXSofaf/BndqDgdfMODgmUH2xdPHNtyX8kOAm+P1u9QunYyA4J1verB3on RzjpGX4lzNHJT6wzsYmHkfaDahYi+Kh2RXHzImdCkqYLfAUO9gRi9uoGk+D2carAFtlG GjB0Ka03CVgFP+ogf/4y527klsCnJ82VJWJ2YgoinBgp+qSaVFN1s1t2p0TB5Yp4Y8Np UhSQ== MIME-Version: 1.0 References: <20190811165916.GX31406@gate.crashing.org> <20190812175450.GB31406@gate.crashing.org> <20190812215224.GC31406@gate.crashing.org> <20190814072127.GE31406@gate.crashing.org> <20190814202102.GI31406@gate.crashing.org> <20190814210015.GJ31406@gate.crashing.org> In-Reply-To: From: Tejas Joshi Date: Thu, 15 Aug 2019 13:55: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, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00108.txt.bz2 > 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. In that case, something like FADD. But for functions like fsub, fmul and fdiv that does similar computation, wouldn't we need more operation codes for them? Is it possible to have something generalized that does *arithmetic computation (rather than just addition)* and then *conversion (narrowing)*? just a thought. Thanks, Tejas On Thu, 15 Aug 2019 at 18:17, 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 > > 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. > > 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. > > Thanks, > Richard