From patchwork Thu Jul 14 02:44:10 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 648149 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rqg5z42Wfz9sDG for ; Thu, 14 Jul 2016 12:44:52 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=lvJvq+9F; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=qbSeaieyPhem6RVQH FQw2P5OM9RAvesoZXPOlA1CeC0jO/zyUzVD6hdJ9up/dFxZA1oGTuJxa3YAtkBdi lGdX5VgZlKIw6srmNoenTGB/pQtZXVD1hjdQaLh4XWiY6vMPGwt3BzPn9s2poXCy GnK34wejyGf6GPqAVBVyQlxfe0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=MOlzsZYbu7GcqxsMFtYEWxh MbUM=; b=lvJvq+9FNDdoq9VaUf98/+Z209P/6S7JQ3E81pLEhRlM2Wj9wpogFat lq8NmN2HWZEu6NxZi+fkuIi9PNYgC5sDKNQFjdrnBG53B8j2CsrWTc3ANbqzR+lt Fy9SeXt0BzuyfCTwHaJhu4keo6aoys5iaX89vk9VnG5dpRouwoFw= Received: (qmail 55437 invoked by alias); 14 Jul 2016 02:44:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 55338 invoked by uid 89); 14 Jul 2016 02:44:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=multichar, Hx-languages-length:2904, Yr, disappeared X-HELO: mail-pa0-f41.google.com Received: from mail-pa0-f41.google.com (HELO mail-pa0-f41.google.com) (209.85.220.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 14 Jul 2016 02:44:18 +0000 Received: by mail-pa0-f41.google.com with SMTP id fi15so23460845pac.1 for ; Wed, 13 Jul 2016 19:44:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=6hq1PevkZRnReiqd1b28lSmEsmnnsDsjK5eQJL2GwQc=; b=UaZSxdmOl6fs8SJ5CbNAIdJj75xRdQBVcuEJKnsNP6o/YFc7uKMvqvnT550ErDgoIX nqLzN196UYYLJz0q4Gn/kqqk7OES+BHV6FGupQGnRHJZ/lzazghu5AD/RqLgxaCxfZ4i msbAgtd09GFADa9MIolxxTVpAERhiayX4x0gOC3V2FPdKSJiieexIMu1H7O3kdUkDMZH 9sxZ9bS2Z1TKPjAh7E/lvpfQzb3mGmyBDVYkcoZphf/pZjr9+10pwgLciVoxpDICA5li vIKH41TzcRS8Io2ot+xJD+BJKkqhc7QiTtgsHrpHCYKigGtNOby8yUjl9t9/D4M+qRyy rKig== X-Gm-Message-State: ALyK8tLJFQ2/uACAjC7GItfDQmo20rJq4kQlAjpGPAYQ8dFaNtIFJpogSOahgGAJfQTpJA== X-Received: by 10.66.77.194 with SMTP id u2mr18869492paw.90.1468464256699; Wed, 13 Jul 2016 19:44:16 -0700 (PDT) Received: from bubble.grove.modra.org (CPE-58-160-146-233.sa.bigpond.net.au. [58.160.146.233]) by smtp.gmail.com with ESMTPSA id sk4sm65392pac.16.2016.07.13.19.44.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jul 2016 19:44:15 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id BC785CA62C; Thu, 14 Jul 2016 12:14:10 +0930 (ACST) Date: Thu, 14 Jul 2016 12:14:10 +0930 From: Alan Modra To: Segher Boessenkool Cc: Peter Bergner , David Edelsohn , GCC Patches , Ulrich Weigand , Bill Schmidt Subject: Re: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx Message-ID: <20160714024410.GD1632@bubble.grove.modra.org> References: <20160712134848.GI700@bubble.grove.modra.org> <20160712141723.2B5B23BED@oc7340732750.ibm.com> <20160713005720.GJ700@bubble.grove.modra.org> <20160713052701.GA1632@bubble.grove.modra.org> <20160713114621.GA9048@gate.crashing.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160713114621.GA9048@gate.crashing.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes On Wed, Jul 13, 2016 at 06:46:22AM -0500, Segher Boessenkool wrote: > On Wed, Jul 13, 2016 at 02:57:01PM +0930, Alan Modra wrote: > > This is what I've bootstrapped and regression tested on > > powerpc64le-linux. I'm using Peter's testcases from this thread > > rather than the one in the original patch submission, because that one > > relies on -O0 not reducing the function down to a nop. OK to apply? > > This is okay. Does it need a backport? Okay for 6 as well, then. Yes, gcc-6 needs the patch too. > We all agreed the question marks would be a good idea, but you say it > causes some testcases to fail. Could you investigate please? After much head-scratching (danger of splinters) I noticed that I'd written '*?r' in the patch rather than '?*r'. That explained failures like gcc.target/powerpc/ppc-vector-memset.c using gprs rather than vrs for the memset expansion. According to md.text, '*' says the following char should be ignored when choosing register preferences. (Which is a bug, since the advent of multi-char constraints, and potentially affects us with our use of constraint strings like "?*wb".) Anyway, what was ignored for reg allocation was the '?', not 'r'. Also, '*Y' is a bit pointless since 'Y' isn't a register constraint. The '*' belongs on the corresponding operand 1 'r'. I also saw ICEs in rs6000_split_multireg_move on a number of gcc.dg/vmx testcases, but the ICEs disappeared with the constraints fixed. I can't give you the exact rtl involved now since my debug session had a connection timeout, but it was this assert: gcc_assert (GET_CODE (XEXP (dst, 0)) == PLUS && REG_P (basereg) && REG_P (offsetreg) && REGNO (basereg) != REGNO (offsetreg)); and we had an altivec MEM with an AND address for the destination of a SET with gprs for the source. Probably quite easily fixed by stripping off the AND. The following has now been bootstrapped and regression tested on powerpc64le-linux. OK for mainline? * gcc/config/rs6000/altivec.md (altivec_mov): Disparage gpr alternatives. Correct '*' placement on Y,r alternative. Add '*' on operand 1 of r,r alternative. diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md index aa01ac9..9193f07 100644 --- a/gcc/config/rs6000/altivec.md +++ b/gcc/config/rs6000/altivec.md @@ -222,8 +222,8 @@ ;; Vector move instructions. (define_insn "*altivec_mov" - [(set (match_operand:VM2 0 "nonimmediate_operand" "=Z,v,v,*Y,*r,*r,v,v,*r") - (match_operand:VM2 1 "input_operand" "v,Z,v,r,Y,r,j,W,W"))] + [(set (match_operand:VM2 0 "nonimmediate_operand" "=Z,v,v,?Y,?*r,?*r,v,v,?*r") + (match_operand:VM2 1 "input_operand" "v,Z,v,*r,Y,*r,j,W,W"))] "VECTOR_MEM_ALTIVEC_P (mode) && (register_operand (operands[0], mode) || register_operand (operands[1], mode))"