From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7235 invoked by alias); 11 Aug 2019 04:58:24 -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 7227 invoked by uid 89); 11 Aug 2019 04:58:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.5 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= X-HELO: mail-ed1-f53.google.com Received: from mail-ed1-f53.google.com (HELO mail-ed1-f53.google.com) (209.85.208.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 11 Aug 2019 04:58:23 +0000 Received: by mail-ed1-f53.google.com with SMTP id x19so94497396eda.12 for ; Sat, 10 Aug 2019 21:58:21 -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=9fvxd8kAItdB9HPFwezxY+LWW6Kg7d3YzbDbmKXLLys=; b=j30YwGFSrimXFNiG7yXqHzmaRt7jW/TuTy6+4ocxbGW7egiuM/3NRCm2V1uOuQCns0 15y2gjysDKjO8ScstvmKnV6imySRWkdnE19zUE+xlbuqz3TiMvi+2Nmwe/Ci2GqJqNQs UKfgm86z9ul85Xb8taMoI4+eGGldj9KH0DUos3bq4ukypFeqGLNegSP1vIZPMmUyLWHG zpAetRKKYeZsAIzN40cwNli0sgLIv0iU4B/oNtQs242xmW2ZlM0AX+eXk8wpYpoj/Rmj DkRzfzWPTaIvfNIJJ5v6a0pb4QdnahMBgUxGmJBPeeJACuvFWOd8cvS8q6OODj3Edl9S nI5g== MIME-Version: 1.0 References: <87sgqnx4i6.fsf@oldenburg2.str.redhat.com> <20190731144722.GS31406@gate.crashing.org> <20190808200514.GL31406@gate.crashing.org> <20190810164600.GT31406@gate.crashing.org> In-Reply-To: <20190810164600.GT31406@gate.crashing.org> From: Tejas Joshi Date: Sun, 11 Aug 2019 04:58: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/msg00084.txt.bz2 Hi! > As far as I understand that flag should set the behaviour of the fadd > function, not the __builtin_fadd one. So I don't know. According to ISO/IEC TS 18661, I am supposed to implement the fadd variants for folding and expand them inline, that take double and long double as arguments and return addition in appropriate narrower type, float and double. As far as I know, we use __builtin_ to call the internal functions? I do not know which the only fadd function is. > double precision one. But instead you want to add two double precision > numbers, producing a single precision one? The fadds instruction fits Yes. > well to that, but you'll have to check exactly how the fadd() function > should behave with respect to rounding and exceptions and the like. In Joseph's initial mail that describes what should be carried out in the course of project, about rounding and exceptions. I have strictly followed this description for my folding patch : * The narrowing functions, e.g. fadd, faddl, daddl, are a bit different from most other built-in math.h functions because the return type is different from the argument types. You could start by adding them to builtins.def similarly to roundeven (with new macros to handle adding such functions for relevant pairs of _FloatN, _FloatNx types). These functions could be folded for constant arguments only if the result is exact, or if -fno-rounding-math -fno-trapping-math (and -fno-math-errno if the result involves overflow / underflow). Thanks, Tejas On Sat, 10 Aug 2019 at 22:16, Segher Boessenkool wrote: > > Hi! > > On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote: > > I have been trying to write a basic pattern taking all the suggestions > > you both have mentioned. The same patch is attached here, but I cannot > > see call to : > > > > float > > foo (double x, double y) > > { > > return __builtin_fadd (x, y); > > } > > being expanded to any instruction, at least a simple one, using > > -fno-builtin-fadd (and also -mhard-float?). It always stays "bl fadd". > > What am I missing here? > > As far as I understand that flag should set the behaviour of the fadd > function, not the __builtin_fadd one. So I don't know. > > > > (POWER8 and later) on. (The result if OE=1 or UE=1 is undefined). (See > > > 4.3.5.1 in the ISA). > > > > 4.3.5.1 in the ISA says that single precision arithmetic instructions > > perform operation in double format and coerces the result in single > > format. Can fadd be considered as this type of instruction or do I > > need to perform add in DFmode and then use "instruction provided to > > explicitly convert double format operand in FPR to single format."? > > A single precision add is "fadds". It rounds its result to single > precision. > > I'm lost what the exact semantic of the wanted fadd() function are. > I thought you wanted to add two single precision numbers, producing a > double precision one. But instead you want to add two double precision > numbers, producing a single precision one? The fadds instruction fits > well to that, but you'll have to check exactly how the fadd() function > should behave with respect to rounding and exceptions and the like. > > > Segher