From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7542 invoked by alias); 21 May 2019 10:12:40 -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 7534 invoked by uid 89); 21 May 2019 10:12:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:BYAPR01, our X-HELO: mail-lf1-f67.google.com Received: from mail-lf1-f67.google.com (HELO mail-lf1-f67.google.com) (209.85.167.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 May 2019 10:12:39 +0000 Received: by mail-lf1-f67.google.com with SMTP id h13so12621048lfc.7 for ; Tue, 21 May 2019 03:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lm2xRXut2gI5rL2DHG6d5lkcWnXHYU3i8DS7L6mPajM=; b=Qx58gqjY+bLlz4ThLg9MPep7Ur37JShR+bonV85zm4bdmjD3r86C8YSc7KnajgVTlx wYpfUDWFsJRArgpbYTC7v1891pssqa3ChNsjKZF2wKgJt+rKIxRWcKM2LjSsAISfRgAh VXT+bsPmD0MvMjk+WVmi0ndAgRoGZbKH1iV3Gpg6JJD/fuygAe+5DrJv/rd+yDlb8duV A6DPPHbQLqlRKxtpnV4T1+1uDZRYXHkdXMJWK1Osub55DHCgajRd8G02Pt958V6tWpiq XqxHXuDqPAOiSlSFXUNkizaxb9gehBQ8X/SFm9r78U/fhT1IerRy4/bRg4lQLre0Zexr Qg+g== MIME-Version: 1.0 References: <334e4382-d393-4a83-0fa6-abd80a949f44@redhat.com> In-Reply-To: From: Richard Biener Date: Tue, 21 May 2019 10:12:00 -0000 Message-ID: Subject: Re: [PATCH] Remove empty loop with assumed finiteness (PR tree-optimization/89713) To: Feng Xue OS Cc: "gcc-patches@gcc.gnu.org" , Jeff Law Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg01370.txt.bz2 On Mon, May 20, 2019 at 4:51 PM Feng Xue OS wrote: > > > 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 ensure 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 because the loop might be removed. > > Suppose we have a function: > > void foo(int bound) > { for (int i = 0; i <= bound; i++); } > > In an early CD-DCE pass, "bound" is represented as a variable, and loop has 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. But if "bound" is always INT_MAX but that's not visible to the compiler we will still remove the loop so I see no difference with removing it always. > This is why I suggest doing the optimization as late as possible. But this will defeat the purpose of allowing followup optimizations. IMHO the only "sensible" thing is to do Index: gcc/tree-ssa-dce.c =================================================================== --- gcc/tree-ssa-dce.c (revision 271415) +++ gcc/tree-ssa-dce.c (working copy) @@ -417,7 +417,7 @@ find_obviously_necessary_stmts (bool agg } FOR_EACH_LOOP (loop, 0) - if (!finite_loop_p (loop)) + if (!loop_has_exit_edges (loop)) { if (dump_file) fprintf (dump_file, "cannot prove finiteness of loop %i\n", loop->num); that also has the obvious advantage that we don't need to replace the loop with a trap() but have a place to forward control flow to. The loop in the following testcase is then successfully removed: int main(int argc, char **argv) { unsigned i = argc; while (i+=2); return 0; } Likewise is the loop void **q; int main(int argc, char **argv) { void **p = q; while (p = (void **)*p); return 0; } (that's the pointer-chasing). Not with -fnon-call-exceptions -fexceptions though. Richard. > Feng >