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 3392D3858404; Tue, 19 Oct 2021 07:20:53 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3392D3858404
From: "aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102814] [12 regression]
 quadratique/exponential time complexity for max-jump-thread-duplication-stmts
Date: Tue, 19 Oct 2021 07:20: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: 12.0
X-Bugzilla-Keywords: compile-time-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aldyh at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102814-4-tTTm9dJkmt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102814-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102814-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: Tue, 19 Oct 2021 07:20:53 -0000

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

--- Comment #1 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Dmitry G. Dyachenko from comment #0)
> r12-4256 FAST
> r12-4444 SLOW
>=20
> g++ -fpreprocessed -std=3Dc++98 -O2 --param
> max-jump-thread-duplication-stmts=3DNNN -c x.ii

Well, you are basically eliding the fail safe we put in specifically for th=
is
code explosion:

  /* Threading through an empty latch would cause code to be added to
     the latch.  This could alter the loop form sufficiently to cause
     loop optimizations to fail.  Disable these threads until after
     loop optimizations have run.  */
  if ((threaded_through_latch
       || (taken_edge && taken_edge->dest =3D=3D loop->latch))
      && !(cfun->curr_properties & PROP_loop_opts_done)
      && empty_block_p (loop->latch))
    {
      if (dump_file && (dump_flags & TDF_DETAILS))
        fprintf (dump_file,
                 "  FAIL: Thread through latch before loop opts would create
non-empty latch\n");
      return false;

The default is 15, and you're pushing it to > 180.  Nothing good can come of
that.

That being said, in this very specific case, thread3 is creating some monst=
er
PHIs which then thread4 further explodes.  Luckily this combination is
disallowed by the pending threading restrictions in the presence of loops h=
ere:

https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581894.html

But really, bad things can happen when you disable the fail-safe mechanisms
we've put in place.

Question to the larger audience... do we support bug reports against intern=
al
--param constructs?=