From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from mx2.suse.de (mx2.suse.de [195.135.220.15])
 by sourceware.org (Postfix) with ESMTPS id C28B7385F01D
 for <gcc-patches@gcc.gnu.org>; Thu,  2 Apr 2020 09:41:23 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C28B7385F01D
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org;
 spf=pass smtp.mailfrom=rguenther@suse.de
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
 by mx2.suse.de (Postfix) with ESMTP id 24D72AB8F;
 Thu,  2 Apr 2020 09:41:21 +0000 (UTC)
Date: Thu, 2 Apr 2020 11:41:22 +0200 (CEST)
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
cc: Jason Merrill <jason@redhat.com>, gcc-patches@gcc.gnu.org, 
 "Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: [PATCH][RFC] c/94392 - only enable -ffinite-loops for C++
In-Reply-To: <20200402091746.GP2212@tucnak>
Message-ID: <nycvar.YFH.7.76.2004021133250.830@zhemvz.fhfr.qr>
References: <nycvar.YFH.7.76.2004011532270.830@zhemvz.fhfr.qr>
 <0f331251-85c6-2cfe-e7aa-54bc7966ce57@redhat.com>
 <nycvar.YFH.7.76.2004021110110.830@zhemvz.fhfr.qr>
 <20200402091746.GP2212@tucnak>
User-Agent: Alpine 2.21 (LSU 202 2017-01-01)
MIME-Version: 1.0
X-Spam-Status: No, score=-16.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2020 09:41:25 -0000

On Thu, 2 Apr 2020, Jakub Jelinek wrote:

> On Thu, Apr 02, 2020 at 11:12:48AM +0200, Richard Biener wrote:
> > > "The implementation may assume that any thread will eventually do one of the
> > > following:
> > >  — terminate,
> > >  — make a call to a library I/O function,
> > >  — perform an access through a volatile glvalue, or
> > >  — perform a synchronization operation or an atomic operation.
> > > [Note: This is intended to allow compiler transformations such as removal of
> > > empty loops, even when termination cannot be proven. — end note]"
> 
> With -ffinite-loops, do we actually not optimize if the loop has volatile accesses
> or atomics or library I/O calls?

We don't remove the loop then, yes.  All of those are considered 
side-effects by GCC and thus they are considered needed and keep
the loop live.  From a technical point finite_loop_p will still
return true for those which is not correct but harmless at the
moment (I hope).  I read the above as

volatile int i;

int __attribute__((const,noinline)) baz(int i) { return i; }
int foo(int a)
{
  do
    {
      i;
      if (a != baz(a)) return 1;      
    }
  while (1);
}

being a valid endles loop which we indeed preserve.  But we notice
the opportunity to unswitch on the condition and elide _that_ loop:

  <bb 2> [local count: 118111600]:
  _1 = baz (a_4(D));
  if (_1 != a_4(D))
    goto <bb 4>; [11.00%]
  else
    goto <bb 3>; [89.00%]

  <bb 3> [local count: 955630224]:
  vol.0_5 ={v} i;
  goto <bb 3>; [100.00%]

  <bb 4> [local count: 118111600]:
  vol.0_3 ={v} i;
  return 1;

thus turn it into

  if (a != baz(a)) { i; return 1; }
  do { i; } while (1);

Richard.