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 4913E3858412; Mon, 24 Jan 2022 18:09:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4913E3858412
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/104203] [12 Regressions] huge compile-time
 regression since r12-6606-g9d6a0f388eb048f8
Date: Mon, 24 Jan 2022 18:09:09 +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: 12.0
X-Bugzilla-Keywords: compile-time-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: msebor at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-104203-4-7LEFxfZn3R@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104203-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104203-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2022 18:09:09 -0000

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

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #5)
...
> Martin, can you add a new timevar to timevar.def and use that in
> pass_data_waccess please?

Will do.  The bottleneck is the PHI handling in the access warning pass:

 access analysis                    : 242.88 ( 75%)   0.02 (  7%) 243.12 ( =
75%)
   29k (  0%)

There are thousands of basic blocks each with thousands of PHI nodes that a=
ll
reference each other like this:

  <bb 5> [local count: 354193067]:
  # v0_3233(ab) =3D PHI <v0_1065754(D)(ab)(4), v0_3234(ab)(6)>
  # v1_4045(ab) =3D PHI <v1_1065755(D)(ab)(4), v1_4046(ab)(6)>
  # v2_4857(ab) =3D PHI <v2_1065756(D)(ab)(4), v2_4858(ab)(6)>
  ...
  <bb 6> [local count: 177676792]:
  # v0_3234(ab) =3D PHI <v0_1065754(D)(ab)(3), v0_3233(ab)(5), v0_3233(ab)(=
8),
..., v0_4044(ab)(5251), v0_4044(ab)(5252), v0_4044(ab)(5253)>=20
  # v1_4046(ab) =3D PHI <v1_1065755(D)(ab)(3), v1_4045(ab)(5), v1_4045(ab)(=
8),
..., v1_4856(ab)(5251), v1_4856(ab)(5252), v1_4856(ab)(5253)>
  ...

The access pass has a limit on recursive PHIs but none on this sort of thin=
g.=20
Let me see what might be a good way to detect this pattern and limit the
processing.

>=20
> Note with -w the compile-time regression is _not_ fixed.  We have
>=20
> bool
> pass_waccess::gate (function *)
> {
>   return (warn_free_nonheap_object
>           || warn_mismatched_alloc
>           || warn_mismatched_new_delete);
> }
>=20
> but it seems -w doesn't disable those?  Only -Wno-free-nonheap-object wor=
ks
> here :/  (I guess there might be a bug about -w not disabling warnings
> enabled by default)

Since the pass issues a bunch other warnings (e.g., -Wstringop-overflow,
-Wuse-after-free, etc.) the gate doesn't seem right.  But since #pragma GCC
diagnostic can re-enable warnings disabled by -w (or turn them into errors)=
 any
gate that considers the global option setting will also interfere with that=
.=