From patchwork Wed Apr 29 09:25:21 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kumar, Venkataramanan" X-Patchwork-Id: 465955 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 EAFE4140320 for ; Wed, 29 Apr 2015 19:25:36 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass reason="1024-bit key; unprotected key" header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=CJQHpltE; dkim-adsp=none (unprotected policy); 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:from :to:cc:subject:date:message-id:content-type :content-transfer-encoding:mime-version; q=dns; s=default; b=yzv KQl/tQv+DNOk6IV64pLqd8vFAAlEcU9dtMR5+6nCfy9po+uVbsBQf1xYBoaaFEIR 4pMsTZeTaIrEYFBDHZchpncV4iQ5F+DS7gGUzI80HcD33PdYAQzEIwsj6qzbzZEl Wz2xku9gatKn8N0LmrCSKqBbfaYDmVAfQuH13I4s= 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:cc:subject:date:message-id:content-type :content-transfer-encoding:mime-version; s=default; bh=iyz+Q+YVS YGAKDWOl4tNMNoK69M=; b=CJQHpltEPqVyEIDgj6iCZmF+DXFvlF2TsQCWwNTLk UPlz+pbQlwL8UCHtvHgMrLPtjsV5Ud94XoyjVI/PRxR/XoONjno4G5XnrdlhPSog uqTLxBkquqtzrHiUaDWFo75tt8bIbh8podAUIqmn4OY9mb37UcqZ+1YAJBQt72nV 8Q= Received: (qmail 127465 invoked by alias); 29 Apr 2015 09:25:30 -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 127455 invoked by uid 89); 29 Apr 2015 09:25:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: na01-by2-obe.outbound.protection.outlook.com Received: from mail-by2on0133.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) (207.46.100.133) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Wed, 29 Apr 2015 09:25:28 +0000 Received: from BY2PR02CA0005.namprd02.prod.outlook.com (25.163.44.143) by CY1PR02MB1117.namprd02.prod.outlook.com (25.163.15.143) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 09:25:24 +0000 Received: from BN1BFFO11FD018.protection.gbl (2a01:111:f400:7c10::1:168) by BY2PR02CA0005.outlook.office365.com (2a01:111:e400:5261::15) with Microsoft SMTP Server (TLS) id 15.1.154.19 via Frontend Transport; Wed, 29 Apr 2015 09:25:24 +0000 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=amd.com; gcc.gnu.org; dkim=none (message not signed) header.d=none; Received-SPF: None (protection.outlook.com: amd.com does not designate permitted sender hosts) Received: from atltwp02.amd.com (165.204.84.222) by BN1BFFO11FD018.mail.protection.outlook.com (10.58.144.81) with Microsoft SMTP Server id 15.1.160.8 via Frontend Transport; Wed, 29 Apr 2015 09:25:24 +0000 X-M-MSG: Received: from satlvexedge01.amd.com (satlvexedge01.amd.com [10.177.96.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by atltwp02.amd.com (Axway MailGate 5.3.1) with ESMTPS id 2FB74BD87A0; Wed, 29 Apr 2015 04:25:21 -0500 (CDT) Received: from SATLEXDAG03.amd.com (10.181.40.7) by satlvexedge01.amd.com (10.177.96.28) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 29 Apr 2015 04:25:41 -0500 Received: from SATLEXDAG06.amd.com ([fe80::1557:d877:7f65:c17]) by satlexdag03.amd.com ([fe80::b5e9:cb70:d30c:3fbc%22]) with mapi id 14.03.0195.001; Wed, 29 Apr 2015 05:25:22 -0400 From: "Kumar, Venkataramanan" To: "Jeff Law (law@redhat.com)" , "segher@kernel.crashing.org" , "gcc-patches@gcc.gnu.org" CC: "maxim.kuvyrkov@linaro.org" Subject: [RFC]: Remove Mem/address type assumption in combiner Date: Wed, 29 Apr 2015 09:25:21 +0000 Message-ID: <7794A52CE4D579448B959EED7DD0A4723DCE9F34@satlexdag06.amd.com> MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.222; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(428002)(189002)(199003)(55846006)(2900100001)(5250100002)(2501003)(101416001)(46102003)(5001770100001)(2920100001)(23726002)(46406003)(53416004)(106466001)(50466002)(47776003)(15975445007)(102836002)(62966003)(77156002)(2656002)(92566002)(229853001)(97756001)(87936001)(105586002)(33656002)(86362001)(54356999)(2930100002)(19580395003)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR02MB1117; H:atltwp02.amd.com; FPR:; SPF:None; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR02MB1117; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR02MB1117; BCL:0; PCL:0; RULEID:; SRVR:CY1PR02MB1117; X-Forefront-PRVS: 05610E64EE X-OriginatorOrg: amd4.onmicrosoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Apr 2015 09:25:24.2617 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96; Ip=[165.204.84.222]; Helo=[atltwp02.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR02MB1117 X-IsSubscribed: yes Hi Jeff/Segher, Restarting the discussion on the GCC combiner assumption about Memory/address type. Ref: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01298.html https://gcc.gnu.org/ml/gcc/2015-04/msg00028.html While working on the test case in PR 63949, I came across the below code in combine.c: make_compound_operation. --snip--- /* Select the code to be used in recursive calls. Once we are inside an address, we stay there. If we have a comparison, set to COMPARE, but once inside, go back to our default of SET. */ next_code = (code == MEM ? MEM : ((code == PLUS || code == MINUS) && SCALAR_INT_MODE_P (mode)) ? MEM : ((code == COMPARE || COMPARISON_P (x)) && XEXP (x, 1) == const0_rtx) ? COMPARE : in_code == COMPARE ? SET : in_code); ---snip-- When we see an RTX code with PLUS or MINUS then it is treated as MEM/address type (we are inside address RTX). Is there any significance on that assumption? I removed this assumption and the test case in the PR 63949 passed. On X86_64, it passes bootstrap and regression tests. But on Aarch64 the test in PR passed, but I got a few test case failures. Tests that now fail, but worked before: gcc.target/aarch64/adds1.c scan-assembler adds\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3 gcc.target/aarch64/adds1.c scan-assembler adds\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3 gcc.target/aarch64/adds3.c scan-assembler-times adds\tx[0-9]+, x[0-9]+, x[0-9]+, sxtw 2 gcc.target/aarch64/extend.c scan-assembler add\tw[0-9]+,.*uxth #?1 gcc.target/aarch64/extend.c scan-assembler add\tx[0-9]+,.*uxtw #?3 gcc.target/aarch64/extend.c scan-assembler sub\tw[0-9]+,.*uxth #?1 gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxth #?1 gcc.target/aarch64/extend.c scan-assembler sub\tx[0-9]+,.*uxtw #?3 gcc.target/aarch64/subs1.c scan-assembler subs\tw[0-9]+, w[0-9]+, w[0-9]+, lsl 3 gcc.target/aarch64/subs1.c scan-assembler subs\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 3 gcc.target/aarch64/subs3.c scan-assembler-times subs\tx[0-9]+, x[0-9]+, x[0-9]+, sxtw 2 Based on in_code , If it is of "MEM" type combiner converts shifts to multiply operations. --snip-- switch (code) { case ASHIFT: /* Convert shifts by constants into multiplications if inside an address. */ if (in_code == MEM && CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT && INTVAL (XEXP (x, 1)) >= 0 && SCALAR_INT_MODE_P (mode)) ---snip---- There are few patterns based on multiplication operations in Aarch64 backend which are used to match with the pattern combiner generated. Now those patterns have to be fixed to use SHIFTS. Also need to see any impact on other targets. But before that I wanted to check if the assumption in combiner, can simply be removed ? Regards, Venkat. PS: I am starting a new thread since I no more have access to Linaro ID from where I sent the earlier mail. diff --git a/gcc/combine.c b/gcc/combine.c index 5c763b4..945abdb 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -7703,8 +7703,6 @@ make_compound_operation (rtx x, enum rtx_code in_code) but once inside, go back to our default of SET. */ next_code = (code == MEM ? MEM - : ((code == PLUS || code == MINUS) - && SCALAR_INT_MODE_P (mode)) ? MEM : ((code == COMPARE || COMPARISON_P (x)) && XEXP (x, 1) == const0_rtx) ? COMPARE : in_code == COMPARE ? SET : in_code);