From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64422 invoked by alias); 31 Jul 2018 22:16:40 -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 64413 invoked by uid 89); 31 Jul 2018 22:16:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=for, for! X-HELO: EUR03-VE1-obe.outbound.protection.outlook.com Received: from mail-eopbgr50047.outbound.protection.outlook.com (HELO EUR03-VE1-obe.outbound.protection.outlook.com) (40.107.5.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 31 Jul 2018 22:16:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m5yquzdBuxX4VUCe9/6ZamfuJGUfPMLKrNwaDXCcniA=; b=nyEonvWHpLGi1QE5C4bg+ptd6XFXKhKJtmDXmqQdDFwCjgAHMY8ca3Px7ZpXdYPleFJARSOOdb+0WR/9Eajsn/vvh/bDibBNMgLqx3R4Y/HeesnAWq8okt7Q4yXC3uz0vh7YXBM1pKBJ7kAhGvnffanyECwLnfU9Tu22clD3maA= Received: from HE1PR0802CA0023.eurprd08.prod.outlook.com (2603:10a6:3:bd::33) by AM6PR08MB3381.eurprd08.prod.outlook.com (2603:10a6:20b:43::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.19; Tue, 31 Jul 2018 22:16:33 +0000 Received: from AM5EUR03FT021.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::209) by HE1PR0802CA0023.outlook.office365.com (2603:10a6:3:bd::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.995.18 via Frontend Transport; Tue, 31 Jul 2018 22:16:33 +0000 Authentication-Results: spf=fail (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; gcc.gnu.org; dkim=none (message not signed) header.d=none;gcc.gnu.org; dmarc=none action=none header.from=arm.com; Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; Received: from nebula.arm.com (40.67.248.234) by AM5EUR03FT021.mail.protection.outlook.com (10.152.16.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1038.3 via Frontend Transport; Tue, 31 Jul 2018 22:16:32 +0000 Received: from AZ-NEU-EX04.Arm.com (10.251.24.32) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1415.2; Tue, 31 Jul 2018 22:16:29 +0000 Received: from arm.com (10.2.206.78) by mail.arm.com (10.251.24.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_RSA_WITH_AES_256_CBC_SHA256) id 15.1.1415.2 via Frontend Transport; Tue, 31 Jul 2018 22:16:29 +0000 Date: Tue, 31 Jul 2018 22:16:00 -0000 From: James Greenhalgh To: Sam Tebbs CC: Sudakshina Das , "gcc-patches@gcc.gnu.org" , Marcus Shawcroft , nd , Richard Earnshaw Subject: Re: [GCC][PATCH][Aarch64] Stop redundant zero-extension after UMOV when in DI mode Message-ID: <20180731221625.GH1826@arm.com> References: <953dbdd2-e20c-4587-3e0d-ad1a65fc93c6@arm.com> <85b58ddb-3da2-67c6-1514-e308201191d3@arm.com> <74da7cb6-485b-3ce4-7901-d10cb6f1ed95@arm.com> <9e7ccf5b-55b9-543d-1f9e-f9ab36e93376@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9e7ccf5b-55b9-543d-1f9e-f9ab36e93376@arm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Return-Path: James.Greenhalgh@arm.com X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg02014.txt.bz2 On Thu, Jul 26, 2018 at 11:52:15AM -0500, Sam Tebbs wrote: > > Thanks for making the changes and adding more test cases. I do however > > see that you are only covering 2 out of 4 new > > *aarch64_get_lane_zero_extenddi<> patterns. The > > *aarch64_get_lane_zero_extendsi<> were already existing. I don't mind > > those tests. I would just ask you to add the other two new patterns > > as well. Also since the different versions of the instruction generate > > same instructions (like foo_16qi and foo_8qi both give out the same > > instruction), I would suggest using a -fdump-rtl-final (or any relevant > > rtl dump) with the dg-options and using a scan-rtl-dump to scan the > > pattern name. Something like: > > /* { dg-do compile } */ > > /* { dg-options "-O3 -fdump-rtl-final" } */ > > ... > > ... > > /* { dg-final { scan-rtl-dump "aarch64_get_lane_zero_extenddiv16qi" > > "final" } } */ > > > > Thanks > > Sudi > > Hi Sudi, > > Thanks again. Here's an update that adds 4 more tests, so all 8 patterns > generated are now tested for! This is OK for trunk, thanks for the patch (and thanks Sudi for the review!) Thanks, James > > Below is the updated changelog > > gcc/ > 2018-07-26  Sam Tebbs  > >         * config/aarch64/aarch64-simd.md >         (*aarch64_get_lane_zero_extendsi): >         Rename to... > (*aarch64_get_lane_zero_extend): ... This. >         Use GPI iterator instead of SI mode. > > gcc/testsuite > 2018-07-26  Sam Tebbs  > >         * gcc.target/aarch64/extract_zero_extend.c: New file >