From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82653 invoked by alias); 17 Jun 2019 07:50:15 -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 82351 invoked by uid 89); 17 Jun 2019 07:50:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 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=HX-Received:Mon, H*RU:sk:mail-ed, HX-HELO:sk:mail-ed, H*r:sk:mail-ed X-HELO: mail-ed1-f45.google.com Received: from mail-ed1-f45.google.com (HELO mail-ed1-f45.google.com) (209.85.208.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jun 2019 07:50:13 +0000 Received: by mail-ed1-f45.google.com with SMTP id k8so14754021eds.7 for ; Mon, 17 Jun 2019 00:50:13 -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=h9vny8C4C+N+NjhmfgFCrDOtQPVjW2DK194APz6Et0A=; b=gUkpv4wMTbPMm3IFW5wOx+un36PgKwlyjhZJ1SD1kD0WEJtyXgoo5wEm6kzLP+fxAf wCqBO7iYuiaHvS3UuOZRm3i59qx2Mckn6AyxsmOppKR0Jpipao9PXB5P1sKMvgmiJqrQ 1/tf/HxuRDRCtVDoZAb4KB53fDAXnTXbKfy/k1LsjLl39hFNf8nAT1ab2b2lYHiTl1dD DXQLaUZ/i37X8n/096XXQvnPgj24RlEktASRK20vN4RA3jctF46npKqzSIrZvHfmoshJ z9Py4UqmHR3yylgpiiP7lYQ7ofVjAZ0E26NgHwz869SZCOnEZhwpmcaPZlaxKQMYkpEp TSSQ== MIME-Version: 1.0 References: <20190530213839.GF31586@gate.crashing.org> In-Reply-To: From: Tejas Joshi Date: Mon, 17 Jun 2019 07:50:00 -0000 Message-ID: Subject: Re: Expanding roundeven (Was: Re: About GSOC.) To: gcc@gcc.gnu.org Cc: Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00154.txt.bz2 Hello. Looking at machine description of functions like ceil/floor and I think specifically: (define_expand "2" Roundeven should be described as define_expand (or within this alongside ceil and floor?) with expand functions to emit instructions in i386-builtins.c? Referring to , operands of these instructions work with xmm registers, memory and imm8 for rounding mode. > existing ROUND_NO_EXC definition in GCC. A new definition will need > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to > rounding to nearest with ties to even, evaluating to 0.) So (ROUND_ROUNDEVEN 0x0) be declared for rounding towards nearest even for rounding mode argument? But reference says that RC field should end up as 00B for rounding ties to even? I am also much confused about machine-type flags used as C conditions. How do we determine which ones to check and does it depends on exceptions and conditions described in the reference? Also, do ROUNDEVEN needs to be defined as (how): (define_int_attr rounding_insn [(UNSPEC_FRNDINT_FLOOR "floor") Thanks, --Tejas On Fri, 14 Jun 2019 at 23:02, Martin Jambor wrote: > > Hi, > > On Fri, Jun 14 2019, Tejas Joshi wrote: > >> Of course the instruction is not present there, that is the next step in > >> your project :-) > > > > Yes, of course, but what I meant was that instructions for existing > > round/ceil functions and not roundeven. If inlining for these > > functions is available, how can I inspect such instructions getting > > inlined maybe in a *.s file? > > Make sure you compile to a target that has the rounding instruction, > i.e. by using an appropriate -march or -mavx) and also specify > -ffast-math on the command line. I have not double checked, but I > assume the latter is necessary (mainly) because it implies > -fno-math-errno and most of the math builtin expansion into instructions > is guarded by check for !flag_errno_math. > > So e.g. my test input: > > double > callplusone (double d) > { > return __builtin_round (d) + 1; > } > > has vroundsd instruction in the output of: > > ~/gcc/trunk/inst/bin/gcc -O2 -S expand_example.c -mavx -ffast-math > > > > > Also, I am trying to find appropriate places to introduce changes for > > roundeven to be inlined. Attached patch is what I have tried so far to > > find the places. > > So far I only quickly glanced over it but it seems to be going in the > right direction. I'll try to answer the rest of your questions as soon > as I can but I also have to look a bit into the machine descriptions > myself first. > > Martin > > > > ix86_expand_roundeven have dummy code for the sake of time. > > > > In i386.md: > > 1. How should roundeven be defined at certain places where existing > > floor is defined as: > > (define_int_attr rounding_insn > > [(UNSPEC_FRNDINT_FLOOR "floor") > > > > 2. Also, can roundeven be handled like round_floor is handled by: > > (define_expand "2" > > but definitely with certain changes of flags, options and macros. > > > > Thanks, > > --Tejas