From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1969 invoked by alias); 13 Jun 2019 12:33:44 -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 1960 invoked by uid 89); 13 Jun 2019 12:33:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy= X-HELO: mail-ed1-f50.google.com Received: from mail-ed1-f50.google.com (HELO mail-ed1-f50.google.com) (209.85.208.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Jun 2019 12:33:42 +0000 Received: by mail-ed1-f50.google.com with SMTP id a14so29108950edv.12 for ; Thu, 13 Jun 2019 05:33:41 -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=GlOBtoGC8EHiXB0Jj4lH8ed7qxkSvz096sQU6VOhJJA=; b=Os6GyqowK1ikMJEl4wh1xEQ2eSuNuTycm3ng5q1wcEJ/JG3L7VbZVLQZUg+p8zSSjA Zzjzc+bjhmiThyOCkSHnodTY5vut52pXWcXQeZcg9HR1HaHgRdm7holwG0ZJZBqgSTiD sSRJZfL13kwuUFQqJ7lJY/1gphn6hAIcQPnVlo2aZLQFg3TsLjggDrdJ+vo0BQymh1qW EebAW/X6FurSDuhk7Wy01bHFKIDDaylx1dQC85Ux5amalysl6cUv2mj5JQ/KSB2bFjM8 puiibR586oH+abYsM9NaRc6Xh78d/jFjD2YAfYzwokL95X1pDq8A6tHEqz0NZrF1dYTA iFlQ== MIME-Version: 1.0 References: <20190530213839.GF31586@gate.crashing.org> In-Reply-To: From: Tejas Joshi Date: Thu, 13 Jun 2019 12:33:00 -0000 Message-ID: Subject: Re: About GSOC. To: gcc@gcc.gnu.org Cc: Martin Jambor , hubicka@ucw.cz Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00126.txt.bz2 Hello. As further part of implementing roundeven is inlining, I was studying machine descriptions and I have a few questions. As suggested, builtin functions provided a strong model for implementing roundeven. Keeping that in mind, I tried to inspect how similar functions (round/ceil) would get inlined. As it is dependent on target machine, (mine is i7, so should be x86_64 ? I wonder why gcc/config/ does not have x86_64 or amd64 directory. Or is it i386 itself as extended?), should *.s file after compilation contain the specific instruction if supported? I was unable to see such kind of instruction on any -O level. Different pattern names are available for machine descriptions , also for round, ceil, etc. Will I have to add such pattern name for roundeven? (is it the same as optab defined in optabs.def?) Thanks, -Tejas On Thu, 13 Jun 2019 at 00:27, Tejas Joshi wrote: > > Hello. > > > I don't think you should have the unreachable "return false;" in is_even. > > The last "else if" can just be "else". > > I don't think return false in is_even is unreachable. As per my > understanding, when one else if is true in the else if ladder, all the > subsequent "else ifs" including "else" are ignored. When REAL_EXP is > less than SIGNIFICAND_BITS, but the number is odd, the inner "if" for > even-odd will not return true in which case should return false. That > case will ignore next "else if" and will reach return false. > > > Suppose REAL_EXP (r) > SIGNIFICAND_BITS. Then the number is definitely > > even, so you should return true, not false. > > for this condition, else if can be modified to just else and return true. > PATCH: > > gcc/ChangeLog: > > 2019-06-12 Tejas Joshi > > * builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN. > * builtins.def: Added function definitions for roundeven function > variants. > * fold-const-call.c (fold_const_call_ss): Added case for function > call and fold_const_conversion call for roundeven function. > * fold-const.c (negate_mathfn_p): Added case for roundeven function. > (tree_call_nonnegative_warnv_p): Added case for roundeven function. > (integer_valued_real_call_p): Added case for roundeven function. > * real.c (is_even): New function. Returns true if real number is > even, otherwise returns false. > (is_halfway_below): New function. Returns true if real number is > halfway between two integers, else return false. > (real_roundeven): New function. Round real number to nearest > integer, rounding halfway cases towards even. > * real.h (real_value): Added descriptive comments. > Added function declaration for roundeven function. > > gcc/testsuite/ChangeLog: > > 2019-06-12 Tejas Joshi > > * gcc.dg/torture/builtin-round-roundeven.c: New test. > * gcc.dg/torture/builtin-round-roundevenf128.c: New test. > > > > On Tue, 11 Jun 2019 at 01:56, Joseph Myers wrote: > > > > On Sun, 9 Jun 2019, Tejas Joshi wrote: > > > > > Hello. > > > I have created another patch which addresses the above points, > > > attached herewith. > > > > I don't think you should have the unreachable "return false;" in is_even. > > The last "else if" can just be "else". > > > > > > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the > > > > least significant bit has value 1 and the number must be an integer). > > > > > > The number is integer because of the whole word spaces is occupied by > > > integer part? > > > Also, why would the least significant bit will have value 1 if > > > REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th > > > position (even or odd)? > > > > My understanding is that the significand is, as per the comments in > > real.c, in the range [0.5, 1.0). There are SIGNIFICAND_BITS bits. The > > bit above the most significant one has value 2^REAL_EXP. The most > > significant one has value 2^(REAL_EXP-1). The least significant one has > > value 2^(REAL_EXP-SIGNIFICAND_BITS). If REAL_EXP == SIGNIFICAND_BITS, > > that means the least significant bit has value 2^0 = 1, and there are no > > bits with value 0.5 or below, so the number is an integer. > > > > -- > > Joseph S. Myers > > joseph@codesourcery.com