From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125649 invoked by alias); 20 May 2019 14:49:55 -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 125638 invoked by uid 89); 20 May 2019 14:49:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=retain, our X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 May 2019 14:49:53 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D2DE3AFF2; Mon, 20 May 2019 14:49:51 +0000 (UTC) Date: Mon, 20 May 2019 14:49:00 -0000 From: Michael Matz To: Richard Biener cc: GCC Patches , Jeff Law , Feng Xue OS Subject: Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713) In-Reply-To: Message-ID: References: <334e4382-d393-4a83-0fa6-abd80a949f44@redhat.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01266.txt.bz2 Hi, On Mon, 20 May 2019, Richard Biener wrote: > > The C++ standard says that do{}while(1) is __builtin_unreachable(), we > > don't have to preserve it. There is no mention of anything like a > > "nontrivial exit condition". Other languages may have a different > > opinion though, so it would probably need a flag indeed... But I am > > curious what the point of such a loop is. > > busy wait until wakeup by signal or interrupt. I'd actually turn it around from what C++ says. If the user wrote, as is, "do{}while(1);" or "while(1);" or "for(;;);" then we can assume something funky going on and not remove the loop. For any other loop we assume that they are finite. I.e. we mark loops as to-be-preserved (which we set on a few known patterns), and just remove all other loops when they contain no observable side effects after optimization. And of course we'd still have to determine what acceptable side effects are. E.g. in a pointer chasing loop containing no body, is the segfault when the pointer chain is not in fact circular, a side effect we should retain, or should we be allowed to remove the loop? I'd say we should remove the loop, of course. (And yes, I've always found our obsession with preserving infinite loops, outside of the above "obvious" cases, overly anal as well) Ciao, Michael.