From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77012 invoked by alias); 20 Aug 2019 19:42:06 -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 77004 invoked by uid 89); 20 Aug 2019 19:42:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=recognised X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Aug 2019 19:42:04 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x7KJftIm021244; Tue, 20 Aug 2019 14:41:56 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7KJfsIA021243; Tue, 20 Aug 2019 14:41:54 -0500 Date: Tue, 20 Aug 2019 19:42:00 -0000 From: Segher Boessenkool To: Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com, richard.sandiford@arm.com Subject: Re: Expansion of narrowing math built-ins into power instructions Message-ID: <20190820194154.GY31406@gate.crashing.org> References: <20190815184450.GO31406@gate.crashing.org> <20190819130720.GG31406@gate.crashing.org> <20190820121137.GP31406@gate.crashing.org> <20190820134613.GR31406@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00165.txt.bz2 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