From patchwork Thu Feb 23 11:24:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bin Cheng X-Patchwork-Id: 731507 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 3vTX2r21Q1z9s7s for ; Thu, 23 Feb 2017 22:25:04 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="cCChldD1"; 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:mime-version; q=dns; s=default; b=XgacJ7eT1c4Ue0TZSUtSokutfqvHekhE542Astp4srHm906Kun e96DhilgX5kynTfnySkX7aGyp8e+7OFuGFkYoHoUdtuRZnoN3aXq7pnc4KuxVmSH XpXNx01BrGsmfU6alHyUSP+qnh1r4Nnp5q6neYF9FiE81DmcjmfWdTN3A= 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:mime-version; s= default; bh=ex3xecqdkWkhsgwOSoLfx91YMMQ=; b=cCChldD1L1Eu5ePHWE/9 i5GwsHSS/7ifB9DbSHL4vInZX+7s3AzSXQV6riMs3B31Cs/5tbwqpc6j4FAc43Df /Pv+q6bK1N1JZBijLL86hUwFk899yZofazCfF4f6tZS2oBYx4lIZC4s7gaOXLSGG pM/HJC4pIadpbWBCYs310Uk= Received: (qmail 109645 invoked by alias); 23 Feb 2017 11:24:45 -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 109497 invoked by uid 89); 23 Feb 2017 11:24:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:3632, H*c:HHH, HContent-Language:en-GB, distance X-HELO: EUR01-VE1-obe.outbound.protection.outlook.com Received: from mail-ve1eur01on0082.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (104.47.1.82) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Feb 2017 11:24:41 +0000 Received: from VI1PR0802MB2176.eurprd08.prod.outlook.com (10.172.12.21) by VI1PR0802MB2175.eurprd08.prod.outlook.com (10.172.12.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 11:24:38 +0000 Received: from VI1PR0802MB2176.eurprd08.prod.outlook.com ([10.172.12.21]) by VI1PR0802MB2176.eurprd08.prod.outlook.com ([10.172.12.21]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 11:24:38 +0000 From: Bin Cheng To: "gcc-patches@gcc.gnu.org" CC: nd Subject: [PATCH PR79663]Only reversely combine refs for ZERO length chains in predcom Date: Thu, 23 Feb 2017 11:24:37 +0000 Message-ID: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Bin.Cheng@arm.com; x-ms-office365-filtering-correlation-id: a978b91e-0642-4015-72aa-08d45bde8dd5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:VI1PR0802MB2175; x-microsoft-exchange-diagnostics: 1; VI1PR0802MB2175; 7:X5nhY7H9GRhw4CuS7oD9/c58S0dtp2+4+2ScxZKbpKlKOl5LVZUIkgB/tkBT8M77miEe7jqv1b3uiwk77Uzh8sHBCKef36YmXaYwvxwWkt1w/ReWGzk6VD/73g76wG0nAQboX793PAZfwFG8wfe5HBZ5dUj6Da7GacCOOftWdWB74JeC+TbU46MOI2NH/TUTQ4BiMG++G6BmeZPcxPBOM08djcCxAN0WRn8lTxa5OtARjm7VZ/xqyDfz/S5p1ru9a5BhraTFOft3GmHaFjtWBHdqaqlK/cQ4yDNM/IT4avWKhP80m6M8NtISh63tZfEMa1mmuAUNd4nNaJQOnlcSMg== nodisclaimer: True x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(180628864354917)(22074186197030)(183786458502308); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:VI1PR0802MB2175; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0802MB2175; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(199003)(377424004)(189002)(6306002)(55016002)(105586002)(99286003)(74316002)(9686003)(99936001)(122556002)(2501003)(77096006)(450100001)(110136004)(3660700001)(3846002)(68736007)(53936002)(33656002)(3280700002)(6116002)(38730400002)(2906002)(102836003)(66066001)(4326007)(8936002)(305945005)(2900100001)(2351001)(8676002)(50986999)(101416001)(106116001)(106356001)(81156014)(81166006)(189998001)(6436002)(86362001)(25786008)(54356999)(6506006)(92566002)(97736004)(7736002)(5660300001)(6916009)(7696004)(5640700003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0802MB2175; H:VI1PR0802MB2176.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 11:24:37.9780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0802MB2175 X-IsSubscribed: yes Hi, This patch resolves spec2k/mgrid regression as reported by PR79663. Root cause has been described thoroughly in comment #1/#2 of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79663 This patch handles ZERO/non-ZERO length chains differently and only reversely combines refs for ZERO length chains. It also does small improvement with in place list swap. Bootstrap and test on x86_64 and AArch64, is it OK? Thanks, bin 2017-01-21 Bin Cheng PR tree-optimization/79663 * tree-predcom.c (combine_chains): Process refs in reverse order only for ZERO length chains, and add explaining comment. diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c index 9723e9c..57d8f7d 100644 --- a/gcc/tree-predcom.c +++ b/gcc/tree-predcom.c @@ -2283,7 +2283,7 @@ combine_chains (chain_p ch1, chain_p ch2) enum tree_code op = ERROR_MARK; bool swap = false; chain_p new_chain; - unsigned i; + int i, j, num; gimple *root_stmt; tree rslt_type = NULL_TREE; @@ -2305,6 +2305,9 @@ combine_chains (chain_p ch1, chain_p ch2) return NULL; } + ch1->combined = true; + ch2->combined = true; + if (swap) std::swap (ch1, ch2); @@ -2317,39 +2320,41 @@ combine_chains (chain_p ch1, chain_p ch2) new_chain->length = ch1->length; gimple *insert = NULL; - auto_vec tmp_refs; - gcc_assert (ch1->refs.length () == ch2->refs.length ()); - /* Process in reverse order so dominance point is ready when it comes - to the root ref. */ - for (i = ch1->refs.length (); i > 0; i--) - { - r1 = ch1->refs[i - 1]; - r2 = ch2->refs[i - 1]; + num = ch1->refs.length (); + i = (new_chain->length == 0) ? num - 1 : 0; + j = (new_chain->length == 0) ? -1 : 1; + /* For ZERO length chain, process refs in reverse order so that dominant + position is ready when it comes to the root ref. + For non-ZERO length chain, process refs in order. See PR79663. */ + for (; num > 0; num--, i += j) + { + r1 = ch1->refs[i]; + r2 = ch2->refs[i]; nw = XCNEW (struct dref_d); nw->distance = r1->distance; - nw->stmt = stmt_combining_refs (r1, r2, i == 1 ? insert : NULL); - /* Record dominance point where root combined stmt should be inserted - for chains with 0 length. Though all root refs dominate following - refs, it's possible the combined stmt doesn't. See PR70754. */ - if (ch1->length == 0 + /* For ZERO length chain, insert combined stmt of root ref at dominant + position. */ + nw->stmt = stmt_combining_refs (r1, r2, i == 0 ? insert : NULL); + /* For ZERO length chain, record dominant position where combined stmt + of root ref should be inserted. In this case, though all root refs + dominate following ones, it's possible that combined stmt doesn't. + See PR70754. */ + if (new_chain->length == 0 && (insert == NULL || stmt_dominates_stmt_p (nw->stmt, insert))) insert = nw->stmt; - tmp_refs.safe_push (nw); + new_chain->refs.safe_push (nw); } - - /* Restore the order for new chain's refs. */ - for (i = tmp_refs.length (); i > 0; i--) - new_chain->refs.safe_push (tmp_refs[i - 1]); - - ch1->combined = true; - ch2->combined = true; - - /* For chains with 0 length, has_max_use_after must be true since root - combined stmt must dominates others. */ if (new_chain->length == 0) { + /* Restore the order for ZERO length chain's refs. */ + num = new_chain->refs.length () >> 1; + for (i = 0, j = new_chain->refs.length () - 1; i < num; i++, j--) + std::swap (new_chain->refs[i], new_chain->refs[j]); + + /* For ZERO length chain, has_max_use_after must be true since root + combined stmt must dominates others. */ new_chain->has_max_use_after = true; return new_chain; }