From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77713 invoked by alias); 16 Nov 2018 14:25:12 -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 77691 invoked by uid 89); 16 Nov 2018 14:25:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=About, nearest, 0.5, closely X-HELO: mail-ed1-f42.google.com Received: from mail-ed1-f42.google.com (HELO mail-ed1-f42.google.com) (209.85.208.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Nov 2018 14:25:08 +0000 Received: by mail-ed1-f42.google.com with SMTP id h15so15022394edb.4 for ; Fri, 16 Nov 2018 06:25:08 -0800 (PST) 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; bh=oWLKXihwvVDBA3mGUKn7ZH8Yv5V+GryjCF8GiGwdT/I=; b=gXLXW81w8bK98GIPp1wCef0eeGm7bVBJQW96EL2b5N9/hzolwrGQ18e8Bpmg9En/e6 hj6zcHBMLcijJix74H3rp1cKcLZwOg6JfU70QMrMQSya/t033yhQzf06UO3Mz5M3DFtP uhgAYkF6pkUprzJ3hmwDQtJf9Bdru6+jfuFQ5G3JzQ8twIl85oYz31unVDKRiXNHKl5I +NBDSxLfFzOU06+znjoXDFD4s+V3NkkF4hKc+HBXZjlQoQMiJAo69erOxwljEiuJJhwt uDkIFKf1dZPz1BtU3NeQmUxJcIyLqBTzZRqmenFXfcT2JvYBtUtIiczpUVQsiAleJmXZ pYPg== MIME-Version: 1.0 References: In-Reply-To: From: Tejas Joshi Date: Fri, 16 Nov 2018 16:50:00 -0000 Message-ID: Subject: Re: About GSOC. To: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00087.txt.bz2 About roundeven, there might be need to add case to expand_builtin_int_roundingfn similar to ceil, for expansion. But how is round() expanded since there's no entry for it in expand_builtin_int_roundingfn ? Also, is it right to have an added case for roundeven in convert.c along CASE_FLT_FN (BUILT_IN_ROUND) in convert_to_integer_1? Thanks. On Tue, 23 Oct 2018 at 22:21, Joseph Myers wrote: > > 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