From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94205 invoked by alias); 7 Apr 2017 07:48:35 -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 94084 invoked by uid 89); 7 Apr 2017 07:48:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=our 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; Fri, 07 Apr 2017 07:48:27 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v377mPqn019896; Fri, 7 Apr 2017 02:48:26 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v377mOxS019895; Fri, 7 Apr 2017 02:48:24 -0500 Date: Fri, 07 Apr 2017 07:48:00 -0000 From: Segher Boessenkool To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org, Kelvin Nilsen Subject: Re: [PATCH] PR80101: Fix ICE in store_data_bypass_p Message-ID: <20170407074824.GU4402@gate.crashing.org> References: <1950447.ugChYOEYFO@polaris> <20170406202902.GS4402@gate.crashing.org> <3316696.3QEehbYcbO@polaris> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3316696.3QEehbYcbO@polaris> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00348.txt.bz2 On Fri, Apr 07, 2017 at 08:54:01AM +0200, Eric Botcazou wrote: > > The only straightforward way I see is to use a rs6000_store_data_bypass_p > > instead, which would be doing the same thing. :-( > > Why not just change the type of the blockage instruction as you suggested? That works for this case, sure, but it won't solve the underlying problem. The default instruction type for rs6000 is "integer". Many instructions have this type: some bswap, register moves, load address/immediate, mtvrsave, nop, and many things that are split; and that is just those that have type "*" (so are easy to search for), not all those that do no explicitly have a type attribute (including blockage). Now, the power6 scheduler defines a bypass from power6-integer (which is types "integer" as well as "add" and "logical") to stores. And then store_data_bypass_p ICEs because not all "integer" insns are a SET or a PARALLEL of SETs. So, changing the type involves changing the default to something else, changing all pipeline descriptions to do the same with that type as it does with "integer", checking all patterns that are type "integer" to see if they should be that new type or not. Or we could just change "blockage" and wait for the next bug report. Alternatively, we can arrange for the bypass functions to not ICE. We can do that specific to these rs6000 pipeline descriptions, by having our own version of store_data_bypass_p; or we can make that function work for all insns (its definition works fine for insn pairs where not both the producer and consumer are SETs). That's what Kelvin's patch does. What is the value in ICEing here? Segher