From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27235 invoked by alias); 12 Nov 2018 17:20:16 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27223 invoked by uid 89); 12 Nov 2018 17:20:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= 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; Mon, 12 Nov 2018 17:20:13 +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 wACHK3r7025910; Mon, 12 Nov 2018 11:20:04 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id wACHK1LU025905; Mon, 12 Nov 2018 11:20:01 -0600 Date: Mon, 12 Nov 2018 17:20:00 -0000 From: Segher Boessenkool To: Andrew Stubbs Cc: Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 21/25] GCN Back-end (part 2/2). Message-ID: <20181112171958.GM23873@gate.crashing.org> References: <4c633833-1954-4b62-1a96-4f1c2cf541fd@codesourcery.com> <4fe09f84-10d6-d30c-e458-27a4a3220eef@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4fe09f84-10d6-d30c-e458-27a4a3220eef@codesourcery.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00973.txt.bz2 On Mon, Nov 12, 2018 at 12:53:26PM +0000, Andrew Stubbs wrote: > >>+/* Implement TARGET_LEGITIMATE_COMBINED_INSN. > >>+ > >>+ Return false if the instruction is not appropriate as a combination > >>of two > >>+ or more instructions. */ > >>+ > >>+bool > >>+gcn_legitimate_combined_insn (rtx_insn *insn) > >>+{ > >>+ rtx pat = PATTERN (insn); > >>+ > >>+ /* The combine pass tends to strip (use (exec)) patterns from insns. > >>This > >>+ means it basically switches everything to use the *_scalar form of > >>the > >>+ instructions, which is not helpful. So, this function disallows > >>such > >>+ combinations. Unfortunately, this also disallows combinations of > >>genuine > >>+ scalar-only patterns, but those only come from explicit expand code. > >>+ > >>+ Possible solutions: > >>+ - Invent TARGET_LEGITIMIZE_COMBINED_INSN. > >>+ - Remove all (use (EXEC)) and rely on md_reorg with "exec" > >>attribute. > >>+ */ > >This seems a bit hokey. Why specifically is combine removing the USE? > > I don't understand combine fully enough to explain it now, although at > the time I wrote this, and in a GCC 7 code base, I had followed the code > through and observed what it was doing. > > Basically, if you have two patterns that do the same operation, but one > has a "parallel" with an additional "use", then combine will tend to > prefer the one without the "use". That doesn't stop the code working, > but it makes a premature (accidental) decision about instruction > selection that we'd prefer to leave to the register allocator. > > I don't recall if it did this to lone instructions, but it would > certainly do so when combining two (or more) instructions, and IIRC > there are typically plenty of simple moves around that can be easily > combined. If you don't want useless USEs deleted, use UNSPEC_VOLATILE instead? Or actually use the register, i.e. as input to an actually needed instruction. If combine is changing an X and a USE to just that X if it can, combine is doing a great job! (combine cannot "combine" one instruction, fwiw; this sometime could be useful (so just run simplification on every single instruction, see if that makes a simpler valid instruction; and indeed a common case where it can help is if the insn is a parallel and one of the arms of that isn't needed). Segher