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 C53223858C35; Thu, 29 Feb 2024 12:59:51 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C53223858C35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709211591;
	bh=jv8hn13vKmP3zhHyj/3p66qs+FN+S6N+ZrL8sa1pXLs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=o1Rjo5e1dv4W/ZixZeRwalhq1jDlnWj/FW3rIAn4oOQm46cSw1GAoIO4FT+0r8ibe
	 u7LcbRh4mSzyXhZ5YMgVHEC3Ps5J0Wb91Cn8LEUXePykDMiRJbngliAZ5AV5cT9W7J
	 a6HMksrx5t4TDWt04y4eKMjgJTULo93d7zYftdDQ=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/113994] [13/14 Regression] Probable C++ code generation
 bug with -O2 on s390x platform
Date: Thu, 29 Feb 2024 12:59:50 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113994-4-YhvIqHCb3m@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113994-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113994-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=3D113994

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> Ick, it's via iv_analysis_loop_init used from doloop and unroll.

In that context I'll note that if it is doloop itself that does the DF
live query then it's doloops fault to not operate within the constraints
of iv_analysis_loop_init.  It might be possible to add a flag to
iv_analysis_loop_init to elide its df_analyze stuff and instead have the
caller do a function-wide DF analysis.

I see doloop_optimize_loops does

  if (optimize =3D=3D 1)
    {
      df_live_add_problem ();
      df_live_set_all_dirty ();
    }

  for (auto loop : loops_list (cfun, 0))
    doloop_optimize (loop);

but never calls df_analyze.  I'm not actually sure what happens if you
then do df_analyze_loops, whether that scraps all but the loop BB
info computed?  Anyway, I don't think that simply adding another problem
"around" iv_analysis_loop_init works as we can see here.  If
iv_analysis_loop_init were to compute liveness it would see that it needs
more that just the loop body blocks.

Also note that my patch while it might work in most cases, isn't fool-proof.
The actual use might be in the very last BB of the function (very unlikely
for CC, of course).  Doing an analysis of all reachable blocks perverts
the use of df_analyze_loop.

So.  It looks all broken design to me (in doloop).=