From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58876 invoked by alias); 20 Aug 2019 14:43:48 -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 57584 invoked by uid 89); 20 Aug 2019 14:43:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy= X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Aug 2019 14:43:46 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2844228; Tue, 20 Aug 2019 07:43:45 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3656C3F246; Tue, 20 Aug 2019 07:43:44 -0700 (PDT) From: Richard Sandiford To: Segher Boessenkool Mail-Followup-To: Segher Boessenkool ,Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com, richard.sandiford@arm.com Cc: Tejas Joshi , gcc@gcc.gnu.org, Martin Jambor , hubicka@ucw.cz, joseph@codesourcery.com Subject: Re: Expansion of narrowing math built-ins into power instructions References: <20190815184450.GO31406@gate.crashing.org> <20190819130720.GG31406@gate.crashing.org> <20190820121137.GP31406@gate.crashing.org> <20190820134613.GR31406@gate.crashing.org> Date: Tue, 20 Aug 2019 14:43:00 -0000 In-Reply-To: <20190820134613.GR31406@gate.crashing.org> (Segher Boessenkool's message of "Tue, 20 Aug 2019 08:46:13 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00159.txt.bz2 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. >> >> 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. 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.) Besides, how much depends on target-independent code not knowing what the rounding mode is? Do you think float_narrow would still make sense even if more information was available at compile time (e.g. if a plus could be annotated with a specific rounding mode)? Or is not knowing the rounding mode a fundamental part of float_narrow being OK for you? > And yes, it is icky. But it is sound, as far as I can see. I really disagree that it's sound, but no point me saying why again :-) (It could certainly be made to work with sufficient hacks of course, like pretty much anything could, but I don't think that's the same thing.) Thanks, Richard