From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27534 invoked by alias); 23 Oct 2018 16:51:41 -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 27512 invoked by uid 89); 23 Oct 2018 16:51:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:ri6k1m9, H*f:sk:ri6k1m9 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Oct 2018 16:51:38 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=svr-ies-mbx-01.mgc.mentorg.com) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gEzu0-0006HJ-Sq from joseph_myers@mentor.com ; Tue, 23 Oct 2018 09:51:33 -0700 Received: from digraph.polyomino.org.uk (137.202.0.90) by svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 23 Oct 2018 17:51:29 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.90_1) (envelope-from ) id 1gEztw-0004xf-NF; Tue, 23 Oct 2018 16:51:28 +0000 Date: Tue, 23 Oct 2018 16:51:00 -0000 From: Joseph Myers To: Martin Jambor CC: Tejas Joshi , Subject: Re: About GSOC. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2018-10/txt/msg00199.txt.bz2 On Tue, 23 Oct 2018, Martin Jambor wrote: > Hi Joseph, > > this seems related to your proposal GSoC proposal in the beginning > of this year. Do you have any comments about Tejas's idea? Do you My proposal was designed so that it would be possible to do some small piece, that is useful by itself, and so learn about some parts of the compiler, and then go onto another piece, and so learn about other parts of the compiler - as there are lots of separate pieces that are related, but each useful by itself as a contribution to GCC. The parts Tejas refers to are good pieces to be looking at for one such piece (roundeven folding for constant arguments) (along with e.g. builtins.def to define the built-in functions). > think this would be a good (part of) a GSoC project next year? If a suitable mentor is available for it next year. > > It does tell that roundeven rounds its argument to nearest integral > > ties to even (least significant bit 0) returning integral value > > provided that the resulting value is exact. > > So, for the start, I'd be implementing this functionality for roundeven. > > As ita said in earlier mails that, similar functions like > > real_ceil are implemented > > in real.c and are used in fold-const-call.c. > > Roundeven might be implemented in similar way. Is it built-in > > (internal) function means not to be exposed to end-user? > > Studying some functions like real_ceil, there are call checks > > (flag_errno_math) so I believe similar would be needed for roundeven. The expectation for this part of the project would be that calls to both __builtin_roundeven and roundeven (and similar functions with f, l, f128 etc. suffixes) would be folded when the arguments are constants (both direct calls with constants such as roundeven (2.5), and cases where GIMPLE optimization passes propagate a constant into the call, such as "double d = 2.5; return roundeven (d);"). This of course involves various internal functions in the compiler to implement that. If you compile code such as double f (void) { double d = 2.5; return ceil (d); } with -O2 -S -fdump-tree-all, you can look at the generated dump files to see which optimization pass the folding into constant 3.0 occurs in. Looking at such dumps is an important way of finding your way around the optimization passes in the compiler. > > In real.c where real_ceil is implemented, there are function calls > > (and implementations) like do_fix_trunc which also then call functions > > like decimal_do_dix_trunc (maybe the main functionality of > > do_fix_trunc?, other are just checks, like NaN or qNaN). I did not You can ignore any cases for decimal floating-point values (do gcc_assert (!r->decimal)), given that the project does not involve adding any decimal floating-point built-in functions. That means you should instead understand REAL_EXP and the significands of floating-point values, and what functions such as clear_significand_below and test_significand_bit do, because you'll need to write your own logic like that in do_fix_trunc, with appropriate cases for whether the bits with values 0.5 and below form part of the significand. > > understand these functions really and what do they do. Also I did not > > understand the structure of REAL_VALUE_TYPE (r->cl and etc?) I suggest looking more closely at the definition of cl in real.h. It's true that it doesn't have a comment specifying its semantics directly, but the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint, along with the values that are stored in that field. By looking at how all the fields in real_value are used, you should be able to deduce their semantics, and then send a GCC patch that adds a comment to each field with a more detailed description of its semantics, which would be a useful contribution by itself to help people reading real.c code in future. (struct real_format has more detailed comments on some of the fields. I suggest using those as a model for the comments that ought to be written for the fields of struct real_value.) > > Also when does the real.c and fold-const-call.c comes in picture in > > the flow of GCC (Is it for GIMPLE level instruction selection (gimple > > stmnt to corresponding rtl instruction))? The code you're looking at is used in GIMPLE optimizations, and possibly folding before GIMPLE. Converting roundeven calls with non-constant arguments to appropriate instructions (for processors that have them, e.g. x86 with SSE 4.1 and later) is also useful, and will involve changes to optabs.def, internal-fn.def and target .md files. But I'd advise doing one self-contained piece first (such as the folding for constant arguments) before moving on to others (such as generating appropriate instructions for the case of non-constant arguments). -- Joseph S. Myers joseph@codesourcery.com