From patchwork Tue Sep 3 20:45:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 1157277 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-508266-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=hotmail.de Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="OXG9OMun"; 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 46NJrt48cHz9sNx for ; Wed, 4 Sep 2019 06:46:20 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:content-type:mime-version; q=dns; s= default; b=vsNPBg9itoHmGbCwTue4hFBeCHGE6bT6biEOOJXkcRad3CvqvFgdk 4KgFvREfhdHQ3ysCQxmF+CKiLDgteNsY6zY2iDkdCRcWpguurJ2IZHLemVPS9oEW FegsHRx5YKeZwewOABDreCutprEwz/q5qG54hyOGZLOBcSeLFcWsmc= 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:from :to:subject:date:message-id:content-type:mime-version; s= default; bh=RMbX1lICUSoBXQoyYfUn6TebyFU=; b=OXG9OMun1jhB0EALzLes FJzIuyunoGpIQCoC3XsnTgv+vO/LreddkTl7RjGTnSzRVj4G0ObepewTnlSAvHpf EG7GxdE5+UfyHf21AhOBZu0y7XzpMGIcZeX5P2Ft3Gg1yCeixlzoV5PSDnICKN05 XaMO9UbmZW/PQL83Ly2QoFY= Received: (qmail 128920 invoked by alias); 3 Sep 2019 20:46:09 -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 128781 invoked by uid 89); 3 Sep 2019 20:45:57 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: EUR02-AM5-obe.outbound.protection.outlook.com Received: from mail-oln040092067099.outbound.protection.outlook.com (HELO EUR02-AM5-obe.outbound.protection.outlook.com) (40.92.67.99) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Sep 2019 20:45:37 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zm8inuh9zjaYgjjPV1n1gUJYVEnnnIJjxu8BQgZLJrhlv9Mt/BngcSrNcF/GDnkcp5I1rE9pUAXb3WI7gOPTHPnp88CjS6koDA/c6OeV7Eai28QFesAZR9Ij7j7aWscUxXjPcoDg1DNQtenFriQyJ2BjYNIPa4ZQ5O/ngz+R0S83Bn3hSa7YqBt9q0DclD3tVBrbGVHwILVUu2llF3LUoF2ec2XKHdRzCPKS3sDF25wOKrcGch8SR6lsC2LRKgmG0Mt9+ltXnXLKiSry/SW+xvUULucDN+YBxnSb+iIs2/bdhgbwcwspEM7TSZzguyoTr7PYmPJqioHwr4ZkE9w7Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JeVqj8qpm1eKOFN9drkzh8BjV0ov4Hyokb9gzUYInUk=; b=DjQEYytkAC820CTkvE9Jo+FYJFE/CVPZO6Wj/BrrydnrBl/tdYmgTK49c8oTNpvDyUdCbC6p0tjN3Avs1nM2Mufod1vl/xeDaxTsWKVYhE7kKWDVOQbdgqfTARLCP34WEtCvwcHIQ5Dxbr10Uf73Su1X4hxDSWKqBKfiCJuWDMtunMzWuGxIQaQ4OYr86mv1iqgKI0o/C7Y+r0rlHEAWMMovqyy/mX3bLiS7UNXIjFfKC+0+7aUzFELO0yPLv28wD67OGoMzwWclyGtRwJqTtWD6ODbmd1ixlJ3PU4oWgLHNE9KYewYJ0Szfa/qlh0/A2OBKJ0XcHhjofqQfMXcpxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from AM5EUR02FT062.eop-EUR02.prod.protection.outlook.com (10.152.8.58) by AM5EUR02HT135.eop-EUR02.prod.protection.outlook.com (10.152.9.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2220.16; Tue, 3 Sep 2019 20:45:26 +0000 Received: from AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM (10.152.8.58) by AM5EUR02FT062.mail.protection.outlook.com (10.152.9.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.16 via Frontend Transport; Tue, 3 Sep 2019 20:45:26 +0000 Received: from AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM ([fe80::2c65:b468:fdc0:d924]) by AM6PR10MB2566.EURPRD10.PROD.OUTLOOK.COM ([fe80::2c65:b468:fdc0:d924%6]) with mapi id 15.20.2220.021; Tue, 3 Sep 2019 20:45:26 +0000 From: Bernd Edlinger To: "gcc-patches@gcc.gnu.org" , Kyrill Tkachov Subject: [PATCH] [ARM] Adjust test expectations of unaligned-memcpy-2/3.c (PR 91614) Date: Tue, 3 Sep 2019 20:45:26 +0000 Message-ID: x-microsoft-original-message-id: <882252da-6ca7-ee7a-90a0-80f11bc62df1@hotmail.de> x-ms-exchange-transport-forked: True MIME-Version: 1.0 Hi, due to the introduction of unaligned_loaddi and unaligned_storedi, two test cases show some regression as PR 91614 points out. I would like to change the test expectations if these two test cases, since they seem to be bogus. That is the test case already failed for arm_prefer_ldrd_strd targets, since not a ldrd or strd is created but a ldm/stm instead, which is probably not what is intended. That is for arm_prefer_ldrd_strd the previously used instruction movdi: (insn 11 10 12 2 (set (mem/c:DI (reg:SI 112) [0 MEM [(voidD.71 *)&destD.5932]+0 S8 A32]) (reg:DI 114)) "unaligned-memcpy-2.c":11:3 642 {*movdi_vfp} (nil)) is split up very early in subreg1 into: (insn 21 10 22 2 (set (mem/c:SI (reg:SI 112) [0 MEM [(voidD.71 *)&destD.5932]+0 S4 A32]) (reg:SI 119)) "unaligned-memcpy-2.c":11:3 640 {*arm_movsi_vfp} (nil)) (insn 22 21 12 2 (set (mem/c:SI (plus:SI (reg:SI 112) (const_int 4 [0x4])) [0 MEM [(voidD.71 *)&destD.5932]+4 S4 A32]) (reg:SI 120 [+4 ])) "unaligned-memcpy-2.c":11:3 640 {*arm_movsi_vfp} (nil)) which is finally replaced by: (insn 35 10 12 2 (parallel [ (set (mem/c:SI (reg/f:SI 3 r3 [111]) [0 MEM [(voidD.71 *)&destD.5932]+0 S4 A32]) (reg:SI 1 r1)) (set (mem/c:SI (plus:SI (reg/f:SI 3 r3 [111]) (const_int 4 [0x4])) [0 MEM [(voidD.71 *)&destD.5932]+4 S4 A32]) (reg:SI 2 r2)) ]) "unaligned-memcpy-2.c":11:3 378 {*stm2_} (expr_list:REG_DEAD (reg:SI 2 r2) (expr_list:REG_DEAD (reg:SI 1 r1) (nil)))) ... so stm instead of strd. Since the unalinged_storedi is an unspec, it is expanded as strd which is kind of okay, but there is register pair spilled which was not there previously: aligned_dest: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. strd r4, [sp, #-8]! ldr r4, [r0] @ unaligned movw r3, #:lower16:.LANCHOR0 ldr r5, [r0, #4] @ unaligned movt r3, #:upper16:.LANCHOR0 strd r4, [r3] ldr r2, [r0, #8] @ unaligned str r2, [r3, #8] ldrh r2, [r0, #12] @ unaligned strh r2, [r3, #12] @ movhi ldrb r2, [r0, #14] @ zero_extendqisi2 strb r2, [r3, #14] ldrd r4, [sp] add sp, sp, #8 bx lr The patch filters out ldrd/strd that sp-relative, and adds a few missing scan-assembler rules, in order to make the test results more stable. Alternative could be to use two movsi instead of the unaligned_load/storedi, but that would end up in ldm/stm which looks plain wrong to me. Tested using various arm-linux-gnueabihf cross-compilers. Is it OK for trunk? Thanks Bernd. 2019-09-03 Bernd Edlinger PR target/91614 * gcc.target/arm/unaligned-memcpy-2.c: Adjust test expectations. * gcc.target/arm/unaligned-memcpy-3.c: Likewise. Index: gcc/testsuite/gcc.target/arm/unaligned-memcpy-2.c =================================================================== --- gcc/testsuite/gcc.target/arm/unaligned-memcpy-2.c (Revision 275341) +++ gcc/testsuite/gcc.target/arm/unaligned-memcpy-2.c (Arbeitskopie) @@ -15,9 +15,11 @@ loads/stores for the remainder. */ /* { dg-final { scan-assembler-times "ldmia" 0 } } */ -/* { dg-final { scan-assembler-times "ldrd" 0 } } */ +/* { dg-final { scan-assembler-times "ldrd\(?!\[^\\n\]*sp\)" 0 } } */ +/* { dg-final { scan-assembler-times "ldm\(?!ia\)" 0 } } */ /* { dg-final { scan-assembler-times "stmia" 1 { target { ! { arm_prefer_ldrd_strd } } } } } */ -/* { dg-final { scan-assembler-times "strd" 1 { target { arm_prefer_ldrd_strd } } } } */ +/* { dg-final { scan-assembler-times "strd\(?!\[^\\n\]*sp\)" 1 { target { arm_prefer_ldrd_strd } } } } */ +/* { dg-final { scan-assembler-times "stm\(?!ia\)" 0 } } */ /* { dg-final { scan-assembler-times "ldrh" 1 } } */ /* { dg-final { scan-assembler-times "strh" 1 } } */ /* { dg-final { scan-assembler-times "ldrb" 1 } } */ Index: gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c =================================================================== --- gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c (Revision 275341) +++ gcc/testsuite/gcc.target/arm/unaligned-memcpy-3.c (Arbeitskopie) @@ -15,10 +15,12 @@ loads/stores for the remainder. */ /* { dg-final { scan-assembler-times "ldmia" 1 { target { ! { arm_prefer_ldrd_strd } } } } } */ -/* { dg-final { scan-assembler-times "ldrd" 1 { target { arm_prefer_ldrd_strd } } } } */ -/* { dg-final { scan-assembler-times "strd" 0 } } */ -/* { dg-final { scan-assembler-times "stm" 0 } } */ -/* { dg-final { scan-assembler-times "ldrh" 1 { target { ! { arm_prefer_ldrd_strd } } } } } */ +/* { dg-final { scan-assembler-times "ldrd\(?!\[^\\n\]*sp\)" 1 { target { arm_prefer_ldrd_strd } } } } */ +/* { dg-final { scan-assembler-times "ldm\(?!ia\)" 0 } } */ +/* { dg-final { scan-assembler-times "stmia" 0 } } */ +/* { dg-final { scan-assembler-times "strd\(?!\[^\\n\]*sp\)" 0 } } */ +/* { dg-final { scan-assembler-times "stm\(?!ia\)" 0 } } */ +/* { dg-final { scan-assembler-times "ldrh" 1 } } */ /* { dg-final { scan-assembler-times "strh" 1 } } */ -/* { dg-final { scan-assembler-times "ldrb" 1 { target { ! { arm_prefer_ldrd_strd } } } } } */ +/* { dg-final { scan-assembler-times "ldrb" 1 } } */ /* { dg-final { scan-assembler-times "strb" 1 } } */