From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30947 invoked by alias); 20 Aug 2019 13:46:34 -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 30805 invoked by uid 89); 20 Aug 2019 13:46:24 -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=H*i:sk:mptlfvo, H*f:sk:mptlfvo, Everything, reg_dead 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 13:46:22 +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 x7KDkEXS003137; Tue, 20 Aug 2019 08:46:14 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id x7KDkDJP003134; Tue, 20 Aug 2019 08:46:13 -0500 Date: Tue, 20 Aug 2019 13:46: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: <20190820134613.GR31406@gate.crashing.org> References: <20190815184450.GO31406@gate.crashing.org> <20190819130720.GG31406@gate.crashing.org> <20190820121137.GP31406@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/msg00158.txt.bz2 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. This was mips64-linux-gcc -Wall -W -O2 -S mulh.c -mips64 -mabi=64 -fdump-rtl-combine-all on === typedef unsigned long S; typedef unsigned __int128 D; S mulh(S a, S b) { return (D)a*b >> (8*sizeof(S)); } === > >> float_narrow is different in that the plus (or whatever operation > >> it's quoting) has to be kept in-place rather than folded away, > >> otherwise the rtx itself is malformed and could trigger an ICE, > >> just like the zero_extend of a const_int that I mentioned. > > > > Yes, it will not pass recog. Structurally it is just hunky-dory though. > > So maybe that's the main point of difference. We're introducing > float_narrow to modify another rtx operation rather than to operate > on an rtx value. I wouldn't say it "operates" on anything. A float_narrow rtx means the thing inside it does single-rounding to SP float. And it is just notation: RTL itself knows *nothing* about float rounding, and because of the way this is structured, nothing can change anything about the float_narrow. And yes, it is icky. But it is sound, as far as I can see. > >> Whatever the number is, we'll still be listing them individually for > >> built-in enumerations, internal_fn, and (I assume) optabs. But maybe > >> after a certain point it does become too unwieldly for rtx codes. > >> We have to keep it within 16 bits at least... > > > > My main concern is all the (simplification) code that parses RTL. All of > > that will have to handle all variant versions as well. > > True, but we'd have to err on the side of caution whatever happens. Yes. > Not all existing PLUS simplifications necessarily apply as-is. Yes. Everything will have to be checked. But not everything will have to be modified, if we pick the defaults carefully. I hope. :-) Segher