From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90379 invoked by alias); 29 Jul 2019 17:17:34 -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 90371 invoked by uid 89); 29 Jul 2019 17:17:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_ASCII_DIVIDERS,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=Breakpoint, trick, HX-Languages-Length:2973 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jul 2019 17:17:32 +0000 X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id BB23EAE1C; Mon, 29 Jul 2019 17:17:29 +0000 (UTC) From: Martin Jambor To: Tejas Joshi , gcc@gcc.gnu.org Cc: hubicka@ucw.cz, joseph@codesourcery.com Cc: Subject: Re: [GSoC-19] Implementing narrowing functions like fadd In-Reply-To: References: User-Agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-suse-linux-gnu) Date: Mon, 29 Jul 2019 17:17:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg00186.txt.bz2 Hi, On Sat, Jul 27 2019, Tejas Joshi wrote: > Hello. > >>> You'll need something different from CASE_MATHFN - these are a different >>> kind of functions that need handling in a different way, because they are >>> parametrized over certain *pairs* of types, rather than over a single >>> type. >> first phase, please just directly test for in the code for >> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process >> those here to get a prototype working. When you add support for more > > Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this > following patch and function is getting folded. good. Please add comments to functions which miss them (real_fadd and fold_const_fadd), for example I am not sure what the return values are supposed to mean, and add a run-time testcase(s) and I'd say you are done for now - after you implement fsub, fmul and fdiv(?) you might want to re-structure some common bits to make the code prettier. > My question is that how the addition and narrowing should be performed > (is it ok to use do_add for addition?). I don't see a reason why it would not be. > As functions in real.c does > not operate on any specific precision, just defining the return type > as float would do the trick? Or do I need to make trailing > out-of-precision bits zero? If yes, having functions like > double_to_float would then be useful or such functions already exist > to do the conversion? I am not sure I understand your question, you have used real_convert in real_fadd and it seems to be doing exactly that? As you know I am not too familiar with this area of gcc but reading the code suggests that and a simple debugging session seems to confirm that (some unimportant gdb output omitted): ---------------------------------------------------------------------- $ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args GNU gdb (GDB; openSUSE Tumbleweed) 8.3 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later (gdb) b real_fadd Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line 5100. (gdb) r Starting program: /home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 -auxbase fadd-fold -Ofast -o fadd-fold.s Breakpoint 1, real_fadd (r=0x7fffffffc580, fmt=..., x=0x7ffff7800060, y=0x7ffff7800080) at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100 5100 do_add (r, x, y, 0); (gdb) n 5101 if (fmt) (gdb) p *r $1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, sig = {0, 0, 10549231767152649216}} (gdb) p/x r->sig[2] $2 = 0x9266666666666400 (gdb) n 5102 real_convert (r, fmt, r); (gdb) 5103 return false; (gdb) p/x r->sig[2] $3 = 0x9266660000000000 ---------------------------------------------------------------------- Thanks, Martin