From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5583 invoked by alias); 9 Nov 2015 22:33:46 -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 5570 invoked by uid 89); 9 Nov 2015 22:33:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f182.google.com Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com) (209.85.217.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 09 Nov 2015 22:33:44 +0000 Received: by lbces9 with SMTP id es9so39765374lbc.2 for ; Mon, 09 Nov 2015 14:33:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.130.138 with SMTP id oe10mr153941lbb.54.1447108421073; Mon, 09 Nov 2015 14:33:41 -0800 (PST) Received: by 10.114.71.114 with HTTP; Mon, 9 Nov 2015 14:33:41 -0800 (PST) In-Reply-To: <20151109221731.GA17072@ibm-tiger.the-meissners.org> References: <20151103202911.GA5304@ibm-tiger.the-meissners.org> <20151109004204.GE17170@ibm-tiger.the-meissners.org> <20151109171627.GA13265@gate.crashing.org> <20151109173419.GC32705@ibm-tiger.the-meissners.org> <20151109195704.GB31155@gate.crashing.org> <20151109221731.GA17072@ibm-tiger.the-meissners.org> Date: Mon, 09 Nov 2015 22:33:00 -0000 Message-ID: Subject: Re: [PATCH], Add power9 support to GCC, patch #5 (ISA 3.0 fusion) From: David Edelsohn To: Michael Meissner , Segher Boessenkool , GCC Patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-11/txt/msg01117.txt.bz2 On Mon, Nov 9, 2015 at 2:17 PM, Michael Meissner wrote: > On Mon, Nov 09, 2015 at 01:11:41PM -0800, David Edelsohn wrote: >> On Mon, Nov 9, 2015 at 11:57 AM, Segher Boessenkool >> wrote: >> > On Mon, Nov 09, 2015 at 12:34:20PM -0500, Michael Meissner wrote: >> >> > > +(define_insn "*toc_fusionload_" >> >> > > + [(set (match_operand:QHSI 0 "int_reg_operand" "=&b,??r") >> >> > > + (match_operand:QHSI 1 "toc_fusion_mem_wrapped" "wG,wG")) >> >> > > + (unspec [(const_int 0)] UNSPEC_FUSION_ADDIS) >> >> > > + (use (match_operand:DI 2 "base_reg_operand" "r,r")) >> >> > > + (clobber (match_scratch:DI 3 "=X,&b"))] >> >> > > + "TARGET_TOC_FUSION_INT" >> >> > >> >> > Do you need that "??r" alternative? Same for the next define_insn. >> >> >> >> Yes unfortunately. The ??r catches the case where r0 is chosen. R0 is not a >> >> base register, and it can't be used for power8 gpr fusion (where you use the >> >> value being loaded for the ADDIS instruction), but it can be used for power9 >> >> fusion (where the ADDIS must be adjancent, but it no longer has to be the >> >> register being loaded). >> > >> > If you have only "b", r0 will not be chosen. Does that help? Or are >> > you generating this pattern from somewhere else where you put in r0? >> >> Mike, >> >> What happens if you leave out the "r" alternative? Does other code >> explicitly generate that pattern with r0? > > Sometimes, one of the passes after reload (usually -fgcse-after-reload) decides > to redo the register allocation, and I would see a failure in building things > like Spec 2006. I have tried not putting the "r" in there, or using > base_reg_operand instead of gpc_reg_operand, but I still got failures. This seems like a bug in those other passes that should be tracked down. Thanks, David