From patchwork Wed Feb 1 16:42:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bill Schmidt X-Patchwork-Id: 722608 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 3vD87J4BW5z9sdn for ; Thu, 2 Feb 2017 03:42:34 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="V1+2y179"; 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:to:cc :from:subject:date:mime-version:content-type :content-transfer-encoding:message-id; q=dns; s=default; b=OnfYK Yo2GM42x0rkRV0+xb4LEMvx3pZ8CqdbKEDZhnIYysj3qz6fGwGu6XMisOtiP38Gf IZc2X6+2Skz4LVTRkmAWA/pge+qfhpkBU0MU1de9xHW6kxhcidMSsyz+PUkYCjxG nApM3KrmI+ZNM7fINOt+VYNN8WFj2Z0UVfPkFA= 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=85uK8AMGsHB ZhhVMMx1p2D261I4=; b=V1+2y179R/i9bEnJXe0nGpunNLK7USA9qxH9us2ippn pZ6XYooZqrQdtHCceWwu0AP0ofUukaHXGC7M5tC7MpAIo9y5tlQ1RE5mjPODMY5w V4F2BD2yCRyjdSeM8tcrO6DkLqMxYB2JtsgS0KCnOQEmT+UI2JKtI287gADw/XOc = Received: (qmail 106698 invoked by alias); 1 Feb 2017 16:42:23 -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 106678 invoked by uid 89); 1 Feb 2017 16:42:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=bit-rotten, bitrotten, 36, 12 X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Feb 2017 16:42:12 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v11GYZA4057412 for ; Wed, 1 Feb 2017 11:42:10 -0500 Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by mx0a-001b2d01.pphosted.com with ESMTP id 28be1nx7fc-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 01 Feb 2017 11:42:10 -0500 Received: from localhost by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Feb 2017 09:42:09 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 1 Feb 2017 09:42:08 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id D0F763E40052; Wed, 1 Feb 2017 09:42:07 -0700 (MST) Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v11Gg7jA9830758; Wed, 1 Feb 2017 09:42:07 -0700 Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ADDC013603C; Wed, 1 Feb 2017 09:42:07 -0700 (MST) Received: from bigmac.rchland.ibm.com (unknown [9.10.86.122]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP id 7270B136046; Wed, 1 Feb 2017 09:42:07 -0700 (MST) To: GCC Patches Cc: Segher Boessenkool , David Edelsohn From: Bill Schmidt Subject: [PATCH, rs6000] Fix PR70012 (gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c) Date: Wed, 1 Feb 2017 10:42:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17020116-0016-0000-0000-0000060A421D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006537; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000201; SDB=6.00815764; UDB=6.00398292; IPR=6.00593206; BA=6.00005108; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014138; XFM=3.00000011; UTC=2017-02-01 16:42:09 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17020116-0017-0000-0000-0000370489ED Message-Id: <65926b1b-a4bf-500a-9cb6-e04f874a168f@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-01_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702010165 X-IsSubscribed: yes Hi, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70012 reports that the subject test case is now failing in some circumstances. Prior to POWER8, the test was checking for conditions that apply when data alignment is unknown; either peeling for alignment or versioning for alignment may be used. With POWER8, however, neither is necessary because we have efficient unaligned memory accesses. So the test case needs some adjustment. Interpreting the original intent of the test case is a little difficult. The use of the vect_alignment_reachable test seems odd. Looking at testsuite/lib/target-supports.exp, vect_alignment_reachable is equivalent to vect_aligned_arrays || natural_alignment_32. But vect_aligned_arrays is always 0 for powerpc*-*-*, so we might as well just be testing natural_alignment_32. It appears that the intent is for peeling to occur for 64-bit Darwin, but otherwise versioning for alignment is expected. So actually vect_alignment_reachable should be replaced by ! natural_alignment_32, and ! vect_alignment_reachable should be replaced by natural_alignment_32. In other words, for whatever reason these tests appear to be backward. I suspect there have been changes to target-supports.exp over time that have left this test slightly bit-rotten. I've added a separate test for whether versioning occurs (which should happen for server targets on POWER7, for example), since just testing for vectorization doesn't test this. I asked Iain Sandoe to test this on Darwin, and he reported that this is not quite right for darwin9 with -m64. Unfortunately he will be traveling for a while and won't be able to investigate till he returns. He's asked me to leave the test as is without skipping Darwin so that the bug for Darwin is not hidden, and he and I will work together to fix that at a later time. But I would like to get this issue cleared up for the server targets now, hence the patch submission. Tested on powerpc64le-unknown-linux-gnu (POWER8) and on powerpc64-unknown-linux-gnu (POWER7) with correct behavior. Is this ok for trunk? Thanks, Bill 2017-02-01 Bill Schmidt * gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Adjust test conditions. Index: gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c =================================================================== --- gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c (revision 245029) +++ gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c (working copy) @@ -36,7 +36,12 @@ int main (void) } /* Peeling to align the store is used. Overhead of peeling is too high. */ -/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" { target vector_alignment_reachable } } } */ +/* { dg-final { scan-tree-dump-times "vectorization not profitable" 1 "vect" { target { ! natural_alignment_32 } } } } */ -/* Versioning to align the store is used. Overhead of versioning is not too high. */ -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target {! vector_alignment_reachable} } } } */ +/* Vectorization occurs, either because overhead of versioning is not + too high, or because the hardware supports efficient unaligned accesses. */ +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { natural_alignment_32 } } } } */ + +/* Versioning to align the store is used. Overhead of versioning is not + too high. */ +/* { dg-final { scan-tree-dump-times "loop versioned for vectorization to enhance alignment" 1 "vect" { target { natural_alignment_32 && { ! vect_hw_misalign } } } } } */