From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@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:29:00 -0000 Message-ID: <7794A52CE4D579448B959EED7DD0A4723DCE9F34@satlexdag06.amd.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 X-SW-Source: 2015-04/txt/msg01843.txt.bz2 Hi Jeff/Segher,=20 Restarting the discussion on the GCC combiner assumption about Memory/addre= ss 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 i= n 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 =3D (code =3D=3D MEM ? MEM : ((code =3D=3D PLUS || code =3D=3D MINUS) && SCALAR_INT_MODE_P (mode)) ? MEM : ((code =3D=3D COMPARE || COMPARISON_P (x)) && XEXP (x, 1) =3D=3D const0_rtx) ? COMPARE : in_code =3D=3D COMPARE ? SET : in_code); ---snip-- When we see an RTX code with PLUS or MINUS then it is treated as MEM/addr= ess type (we are inside address RTX).=20 Is there any significance on that assumption? I removed this assumption an= d the test case in the PR 63949 passed. 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 =3D (code =3D=3D MEM ? MEM - : ((code =3D=3D PLUS || code =3D=3D MINUS) - && SCALAR_INT_MODE_P (mode)) ? MEM : ((code =3D=3D COMPARE || COMPARISON_P (x)) && XEXP (x, 1) =3D=3D const0_rtx) ? COMPARE : in_code =3D=3D COMPARE ? SET : in_code); 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 mul= tiply operations. --snip-- switch (code) { case ASHIFT: /* Convert shifts by constants into multiplications if inside an address. */ if (in_code =3D=3D MEM && CONST_INT_P (XEXP (x, 1)) && INTVAL (XEXP (x, 1)) < HOST_BITS_PER_WIDE_INT && INTVAL (XEXP (x, 1)) >=3D 0 && SCALAR_INT_MODE_P (mode)) ---snip---- There are few patterns based on multiplication operations in Aarch64 backen= d 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 im= pact on other targets. But before that I wanted to check if the assumption in combiner, can sim= ply be removed ? Regards, Venkat. PS: I am starting a new thread since I no more have access to Linaro ID fr= om where I sent the earlier mail.