From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11132 invoked by alias); 15 Aug 2019 09:52:57 -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 11118 invoked by uid 89); 15 Aug 2019 09:52:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.9 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=float_contract, HX-Received:a50, HX-Languages-Length:1427 X-HELO: mail-ed1-f47.google.com Received: from mail-ed1-f47.google.com (HELO mail-ed1-f47.google.com) (209.85.208.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Aug 2019 09:52:55 +0000 Received: by mail-ed1-f47.google.com with SMTP id g8so1649008edm.6 for ; Thu, 15 Aug 2019 02:52:55 -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=gouieeJ/dUgGqB8k/iDo09VQFwgUpPPZPdfA3HOcVmE=; b=pm4lsxyr65AbQhQVX5Ihrx1k/ZYyj7pk+F67BLC9TA7Bp1KN15wRBkdTwTfSXBbbTr blzym3YzvGEhFs2t26tq3kfzQyHrtz+MsH+8luSpbYu1/RQe00+qw7YGNt90Z6Kvp3dx ruw9U7VNMWHsH/PqZT+e4u0jB2pBqbGZGrjTj30RJMu1Evz8HvNjoJwo11olJQ7cPRtv ub1p1jkR1c4iUrzHGBgP6VjovtczQg15Vv44bB2TXfo3EtekEfCQVaj3THOfikNq84uR Tr6lXQMDOSnIjBoB+Yje+xn2ocXHw12rg5l6eC3lPVdmJ7myVzpXMYeFFze7A1bP4DQx bPOA== 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: <20190814210015.GJ31406@gate.crashing.org> From: Tejas Joshi Date: Thu, 15 Aug 2019 09:52: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/msg00106.txt.bz2 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) Thanks, Tejas On Thu, 15 Aug 2019 at 02:30, Segher Boessenkool wrote: > > On Wed, Aug 14, 2019 at 08:23:27PM +0000, Joseph Myers wrote: > > On Wed, 14 Aug 2019, Segher Boessenkool wrote: > > > > > 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? > > > > It's not allowed, but neither is simplifying (a + x) + (b - x) into (a + > > b), when contraction isn't allowed. > > Ah of course. And we already should not do such simplification on RTL, > when contraction is disallowed. > > So yeah it should work fine I think. A new RTL code would be best (it > would be silly to have to make an unspec for it in every port separately), > but an unspec is of course easiest for now. > > > Segher