From patchwork Fri Mar 30 19:29:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Bergner X-Patchwork-Id: 893479 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-475661-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=vnet.ibm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="XtNR7bAH"; dkim-atps=neutral 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 40CWv555KFz9s2b for ; Sat, 31 Mar 2018 06:31:11 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:to:cc :from:subject:date:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=default; b=quYwd xFQABzzhHyoFZmgcuJbeI/5Xvnf+haZFK9hWWEW42EuKBoAj74xix8KNnwsYj9NH aEZHfzRZEmmqmv4O9Vs7/sfwOEwcmaLYsG2Y8yUbHXfKhRI6QYmFzoM3scuCf3ES GIpyxbKFfoW7YgAEiAF2t4mYpHtQoqwoln9vAE= 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:to:cc :from:subject:date:mime-version:content-type :content-transfer-encoding:message-id; s=default; bh=bKwOYjqeD3Q LGDqzYgGMC2t0OFI=; b=XtNR7bAHJqNxEcxfZp4zU1E2CULdOoGnAGMNI2NQLW9 IBVj9WcSC3HFgv3IH1Y7OM+zxnHqZ2QXPTfT7SX+3zgV4P5B0yasvCz7NPXaK0S6 gsR1mhkj+zGZLwZ0lZJDnrf9bPXF4aZaXaaBFraw9JuAcXCoPQEw9XBiHdC7C+6U = Received: (qmail 19451 invoked by alias); 30 Mar 2018 19:31:02 -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 19315 invoked by uid 89); 30 Mar 2018 19:30:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-12.6 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS, TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=010, 258802, vmx, stvx X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Mar 2018 19:30:20 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2UJTicN062003 for ; Fri, 30 Mar 2018 15:30:06 -0400 Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by mx0a-001b2d01.pphosted.com with ESMTP id 2h1rjnxcqc-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Fri, 30 Mar 2018 15:30:05 -0400 Received: from localhost by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 30 Mar 2018 13:30:04 -0600 Received: from b03cxnp08027.gho.boulder.ibm.com (9.17.130.19) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 30 Mar 2018 13:30:01 -0600 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w2UJU1Uc8847856; Fri, 30 Mar 2018 12:30:01 -0700 Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 460ACBE03B; Fri, 30 Mar 2018 13:30:01 -0600 (MDT) Received: from otta.local (unknown [9.80.209.4]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP id 804DBBE038; Fri, 30 Mar 2018 13:30:00 -0600 (MDT) To: GCC Patches Cc: Segher Boessenkool , Michael Meissner , Bill Schmidt From: Peter Bergner Subject: [PATCH, rs6000] Fix PR80546: FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not Date: Fri, 30 Mar 2018 14:29:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 X-TM-AS-GCONF: 00 x-cbid: 18033019-0024-0000-0000-00001827D341 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008772; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000255; SDB=6.01010718; UDB=6.00514986; IPR=6.00789997; MB=3.00020335; MTD=3.00000008; XFM=3.00000015; UTC=2018-03-30 19:30:03 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18033019-0025-0000-0000-00004F514301 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803300196 X-IsSubscribed: yes Currently, the vwx_mov_* move patterns diparage use of GPR registers. This tends to force all modes handled by the move patterns to prefer using VSX registers, even in cases where it doesn't make sense (ie, TImode). The bool3-p[78].c:ptr() test cases are such an example. The following patch is a minimal fix to get test cases PASSing again, by not disparaging GPR usage if the modes are DImode or TImode. Comparing before & after for the ptr4() test case, we now see: - mtvsrd 0,10 - mtvsrd 1,11 - xxpermdi 12,0,1,0 - xxlnor 0,12,12 - mfvsrd 10,0 - xxpermdi 0,0,0,3 - mfvsrd 11,0 + not 10,10 + not 11,11 The plan is to revisit these move patterns again in GCC9 to see if more cleanup and enhancements can be made, but it's too late for that in GCC8. This passed bootstrap and regtesting on both powerpc64le-linux and powerpc64-linux with no regressions. Mike also did a spec comparison with the patch and only found two benchmarks (povray and xalancbmk) with any code differences. The -mcpu=power8 changes for both benchmarks we mostly just address differences. The -mcpu=power9 differences did show a few cases where we generate better code than before (ie, we don't load values into VSX registers just use a direct move them into a GPR register). Is this ok for trunk? This is marked as a GCC7 and GCC8 regression, so ok for GCC 7 too after it has baked on trunk for a while? Peter PR target/80546 * config/rs6000/vsx.md (??r): New mode attribute. (*vsx_mov_64bit): Use it. (*vsx_mov_32bit): Likewise. Index: gcc/config/rs6000/vsx.md =================================================================== --- gcc/config/rs6000/vsx.md (revision 258802) +++ gcc/config/rs6000/vsx.md (working copy) @@ -170,6 +170,22 @@ (define_mode_attr VSa [(V16QI "wa") (TF "wp") (KF "wq")]) +;; A mode attribute to disparage use of GPR registers, except for scalar +;; interger modes. +(define_mode_attr ??r [(V16QI "??r") + (V8HI "??r") + (V4SI "??r") + (V4SF "??r") + (V2DI "??r") + (V2DF "??r") + (DI "r") + (DF "??r") + (SF "??r") + (V1TI "??r") + (TI "r") + (TF "??r") + (KF "??r")]) + ;; Same size integer type for floating point data (define_mode_attr VSi [(V4SF "v4si") (V2DF "v2di") @@ -1200,7 +1216,7 @@ (define_insn_and_split "*xxspltib_ (define_insn "*vsx_mov_64bit" [(set (match_operand:VSX_M 0 "nonimmediate_operand" "=ZwO, , , r, we, ?wQ, - ?&r, ??r, ??Y, ??r, wo, v, + ?&r, ??r, ??Y, , wo, v, ?, *r, v, ??r, wZ, v") (match_operand:VSX_M 1 "input_operand" @@ -1229,7 +1245,7 @@ (define_insn "*vsx_mov_64bit" ;; LVX (VMX) STVX (VMX) (define_insn "*vsx_mov_32bit" [(set (match_operand:VSX_M 0 "nonimmediate_operand" - "=ZwO, , , ??r, ??Y, ??r, + "=ZwO, , , ??r, ??Y, , wo, v, ?, *r, v, ??r, wZ, v")