From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95600 invoked by alias); 21 Aug 2019 17:20:38 -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 95592 invoked by uid 89); 21 Aug 2019 17:20:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.1 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:906 X-HELO: mail-ed1-f52.google.com Received: from mail-ed1-f52.google.com (HELO mail-ed1-f52.google.com) (209.85.208.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Aug 2019 17:20:37 +0000 Received: by mail-ed1-f52.google.com with SMTP id m44so3797327edd.9 for ; Wed, 21 Aug 2019 10:20:36 -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=4x3LBFS3zkitEsdJZGjScsNa1Fo5MgSKyjG5OAzH3Nw=; b=uzvq+hu4UnX7WH1J0Jpq/j6mrYV9aTDlrx7qCbcrf9XZd3GVv15eyG8SObzuhghxrh FtgXmk57maTWUgvMN1cEU4C7xQe2O1fmvwDD6f9SfHzUsdrlMw2ETkpXNY8USDMXH/fh v8gPklRePcaYZ+T3UrPYqQEooc5oQ1Dk/c7Xzz31DaxgVeoaqtWRTnVzNEWHdJYmb2pp wSlYmRenP4ke1pDxH8WheZy8ViUxaS+EHhhLZzyC93FVhyx7+d93AQqwx2z89SOTFiNX UunxxwXguwY1tt7JT7CTKCXk/TOgw6cgczMY1siKaYfb1cp07AeBQmRFKCrgLrSv7mEY ePCw== MIME-Version: 1.0 References: <20190815184450.GO31406@gate.crashing.org> <20190819130720.GG31406@gate.crashing.org> <20190820121137.GP31406@gate.crashing.org> <20190820134613.GR31406@gate.crashing.org> <20190820194154.GY31406@gate.crashing.org> In-Reply-To: <20190820194154.GY31406@gate.crashing.org> From: Tejas Joshi Date: Wed, 21 Aug 2019 17:20:00 -0000 Message-ID: Subject: Re: Expansion of narrowing math built-ins into power instructions To: gcc@gcc.gnu.org Cc: Martin Jambor , hubicka@ucw.cz, segher@kernel.crashing.org, joseph@codesourcery.com Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00174.txt.bz2 Hello. I have the following code which uses unspec but I am really missing something here. Does unspec not work encapsulating plus? Or I have some more places to make changes to? (define_insn "add_truncdfsf3" [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa") (unspec:SF [(plus:DF (match_operand:DF 1 "gpc_reg_operand" "%,wa") (match_operand:DF 2 "gpc_reg_operand" ",wa"))] UNSPEC_ADD_TRUNCATE))] "TARGET_HARD_FLOAT" "@ fadds %0,%1,%2 xsaddsp %x0,%x1,%x2" [(set_attr "type" "fp")]) and an UNSPEC_ADD_TRUNCATE in unspec enum. Thanks, Tejas On Wed, 21 Aug 2019 at 01:12, Segher Boessenkool wrote: > > On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote: > > Segher Boessenkool writes: > > > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote: > > >> Segher Boessenkool writes: > > >> >> [(set (match_operand:SI 0 "register_operand" "=d") > > >> >> (truncate:SI > > >> >> (lshiftrt:DI > > >> > > > >> > (this is optimised to a subreg, in many cases, for example). > > >> > > >> Right. MIPS avoids that one thanks to TARGET_TRULY_NOOP_TRUNCATION. > > > > > > Trying 10 -> 18: > > > 10: r200:TI=zero_extend(r204:DI)*zero_extend(r205:DI) > > > REG_DEAD r205:DI > > > REG_DEAD r204:DI > > > 18: $2:DI=r200:TI#0 > > > REG_DEAD r200:TI > > > Failed to match this instruction: > > > (set (reg/i:DI 2 $2) > > > (subreg:DI (mult:TI (zero_extend:TI (reg:DI 204)) > > > (zero_extend:TI (reg:DI 205))) 0)) > > > > > > I'm afraid not. > > > > That's TI->DI though, whereas the pattern above is DI->SI. The modes > > matter :-) There'd also need to be a shift to match a highpart pattern. > > It's the same for 32-bit: > > mips-linux-gcc -Wall -W -O2 -S mulh.c -mips32 -mabi=32 > (I hope these options are reasonable? I don't know MIPS well at all). > > Trying 12 -> 20: > 12: r200:DI=zero_extend(r204:SI)*zero_extend(r205:SI) > REG_DEAD r205:SI > REG_DEAD r204:SI > 20: $2:SI=r200:DI#0 > REG_DEAD r200:DI > Failed to match this instruction: > (set (reg/i:SI 2 $2) > (subreg:SI (mult:DI (zero_extend:DI (reg:SI 204)) > (zero_extend:DI (reg:SI 205))) 0)) > > The point is that this is the form that this insn is simplified to. If > that form is not recognised by your backend, various optimisation > opportunities are missed. > > > I wouldn't say it knows nothing about rounding. It doesn't know > > what the runtime rounding mode is, but that isn't the same thing. > > (Just like not knowing what (mem:SI (sp)) contains isn't the same > > thing as not knowing anything about stack memory.) > > Does it even know if the rounding mode is one of the IEEE FP rounding > modes? > > > Segher