From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 9C97F3858430; Thu, 22 Feb 2024 14:08:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C97F3858430
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1708610933;
	bh=vEwXRWt8PhmAEbY4WFYc2N5ifryZ72HZM9o5T8dBsuk=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=XYtlC8jEQzBujyIHCSflVsB1Zy6PlmBtfnWjx9rzzAPU07IZq1jImL23TwAVroWyv
	 rgUqmRDuRKqGezKFA6UCQCkSe8eoK9V2Rq3zzEWmG4lhaKLfbBN4ilLjx1SEqFQ1gp
	 0JWCBVl+fUzvJu/3nojTuuDHyrlRf+c9NPNMI1/g=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/114052] [11/12/13/14 Regression] Wrong code
 at -O2 for well-defined infinite loop
Date: Thu, 22 Feb 2024 14:08:53 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114052-4-Otfn5YOJST@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114052-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114052-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114052

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #5)
> So if I understand it right, you want to determine the property that if t=
he
> loop header is executed then BB containing undefined behavior at that
> iteration will be executed, too.
>=20
> modref tracks if function will always return and if it can not determine =
it,
> it will set the side_effect flag. So you can check for that in modref
> summary.
> It uses finite_function_p which was originally done for pure/const detect=
ion
> and  is implemented by looking at loop nest if all loops are known to be
> finite and also by checking for irreducible loops.

I see it doesn't do anything if mark_dfs_back_edges returns false, so it
will claim the function is finite even when it calls a non-finite function?
So I assume this is local analysis only and call edges will be handled
elsewhere?

I found another similar compute, fill_always_executed_in in LIM
(that considers all non-PURE calls as eventually looping, relying
solely on gimple_has_side_effects here).

In the end I want to have this on a stmt granularity (stmts before
calls are OK, stmts after not).

I guess greedily walking loop blocks along edges or walking in RPO oder
and tracking whether there's no possible exit on the way to X would be
the way to go.=