From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44181 invoked by alias); 20 May 2019 08:27:06 -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 44172 invoked by uid 89); 20 May 2019 08:27:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Spam-Relays-External:15.20.1900.020, H*RU:15.20.1900.020, H*r:15.20.1900.020, H*c:alternative X-HELO: NAM01-SN1-obe.outbound.protection.outlook.com Received: from mail-eopbgr820102.outbound.protection.outlook.com (HELO NAM01-SN1-obe.outbound.protection.outlook.com) (40.107.82.102) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 May 2019 08:27:04 +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=5QyeIv1x8OjPY79uEEfGyYT7OLkcbEqMEHVX1FjQEZA=; b=c4wdRtG6OuKSsuIl8/1zcvZrch3cKm6qcS8gRubeAVoD/Ga8ridqSf/1kTg083SMA0pRREfNzh8UHTbF1M7LA8tt61TbRvRbcMV65jQR0/vF7UwFnHBXz9UrEH30pm1NkRmW18WsC7GiL3KA3sUZbWgly/LvphTqi7TjVXhAu9Y= Received: from BYAPR01MB4869.prod.exchangelabs.com (20.177.228.18) by BYAPR01MB3942.prod.exchangelabs.com (52.135.200.157) 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 08:27:00 +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 08:27:00 +0000 From: Feng Xue OS To: Richard Biener , "gcc-patches@gcc.gnu.org" CC: Jeff Law Subject: Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713) Date: Mon, 20 May 2019 08:27: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/msg01196.txt.bz2 >> >> IIUC that was slightly different: "This option tells the loop optimizer = to >> assume that loop indices do not overflow, and that loops with nontrivial >> exit condition are not infinite." >> >> The assumption on indices looks unsafe indeed if it applied to unsigned >> indices in non-empty loops. > The question is of couse what a "nontrivial exit condition" is. Indeed > the general handling of unsigned wrapping was what made the option > useless in practice. > But we thoroughly need to specify "nontrivial exit condition", if going > as far as non-constant exit condition, that is, only do {} while (1) is r= equired > to be detected as infinite then this breaks down to unsigned wrapping IVs > not be infinite. Otherwise it requires the compiler to be able to correc= tly > analyze all unsigned IVs which I know we do not at the moment (SCEV > has limits). > So - any suggestion as to how define "nontrivial exit condition"? >> >> Why exactly are we trying so hard to preserve no-side-effect, infinite >> loops? What are they good for? Note that reading an atomic or volatile >> variable counts as a side effect for this purpose. It looks like some ki= nd >> of busy waiting, but without checking a flag, so it can only be stopped = by >> some external action (say a signal), so if the OS has any notion of sleep >> for a thread, blocking would be better. Or maybe it is running through a >> circular list, ensuring that it stays in RAM? Anyway it seems specific >> enough that that strange code should be the one needing an annotation. > I guess we preserve them because we have to? > I suppose we could add a flag that allows us to elide > loops with no side-effect and non-constant exit condition > (so only preserve do{}while (1))? > Not sure where that would fit best though - certainly not > in niter / IV analysis but in CD-DCE then? Now finiteness assertion is only used in a very late CD-DCE, which is locat= ed after all loop optimizations are done. And we can even place it as late = as just before RTL-expansion. This might be safe enough to let hidden infin= ite loops exposed. Moreover, in CD-DCE, if a loop contains side-effect statements, w/o finiten= ess assertion does not trigger loop removal. Feng