From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130232 invoked by alias); 20 May 2019 14:51:51 -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 130224 invoked by uid 89); 20 May 2019 14:51:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=H*c:alternative, H*c:HHH X-HELO: NAM05-BY2-obe.outbound.protection.outlook.com Received: from mail-eopbgr710110.outbound.protection.outlook.com (HELO NAM05-BY2-obe.outbound.protection.outlook.com) (40.107.71.110) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 May 2019 14:51:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amperemail.onmicrosoft.com; s=selector2-amperemail-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ko81OXca9CmRMvLt+4aauuuoG8+g7rz3fsKWnnpQF0E=; b=1Q//IXuVYJldhlRwcY7xj2M8OxMZmQ60zodj3a+GXEmdYIaY76aypErS9/q7k08PPQ+fruWT/mRvcnn4qQRo2rL7hZhdsqca7jXXE0zL1fk0CGQ9DonYnFuUTJewRijN/xKIJx3zmHH5GEgrewlVSzCerhCPsJuMz0JaRNT58tk= Received: from BYAPR01MB4869.prod.exchangelabs.com (20.177.228.18) by BYAPR01MB5080.prod.exchangelabs.com (20.177.184.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.18; Mon, 20 May 2019 14:51:46 +0000 Received: from BYAPR01MB4869.prod.exchangelabs.com ([fe80::9454:7630:22d5:a934]) by BYAPR01MB4869.prod.exchangelabs.com ([fe80::9454:7630:22d5:a934%7]) with mapi id 15.20.1900.020; Mon, 20 May 2019 14:51:46 +0000 From: Feng Xue OS To: Richard Biener CC: "gcc-patches@gcc.gnu.org" , Jeff Law Subject: Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713) Date: Mon, 20 May 2019 14:51:00 -0000 Message-ID: References: <334e4382-d393-4a83-0fa6-abd80a949f44@redhat.com> , In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=fxue@os.amperecomputing.com; x-ms-oob-tlc-oobclassifiers: OLM:10000; received-spf: None (protection.outlook.com: os.amperecomputing.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-05/txt/msg01268.txt.bz2 > I don't see how it is safe in a late pass when it is not safe in an > earlier one. Optimization is imperfect - we could fail to remove > an "obvious" never taken exit and still have a loop that appears to be > finite according to our definition. Yes. it is. This is somewhat similar to strict-alias option/loop dep pragma. Compiler tries to do something based on hint you tell it, but does not ensu= re correctness. > The only way > to define it would be if there was, at any point, an exit from the > loop (and there it _may_ be exclude EH edges) then > the loop is assumed to be finite. No catch your point. If we treat an infinite loop as finite, it's bad becau= se the loop might be removed. Suppose we have a function: void foo(int bound) { for (int i =3D 0; i <=3D bound; i++); } In an early CD-DCE pass, "bound" is represented as a variable, and loop ha= s a exit, so it is assumed to finite, and is removed. But in a late pass, this function is inlined into another one, and "bound" = has value of INT_MAX, this loop is infinite, and here we can know it should= not be removed. This is why I suggest doing the optimization as late as possible. Feng