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 C1F503858410; Wed, 20 Mar 2024 11:53:19 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1F503858410
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1710935599;
	bh=p62vOOhS2xMiuZSemSpM67v1puOTb0Tu7G35rbrQPyM=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=i5BRgGKK5YEh4McT+EqzTN5n/i7HrtT33LkC63sffy4ojYkeNR0H4km16ruxR7TwD
	 7LQcvHdbyg8/0tA82ceigW05oed4HU/SbVbBjQFGRZa6DUES02pLKZa/uvAr/gArYU
	 m7JDILFgLYA9Y/9KYVLC3wo6J1Ptuzg7oYSJHKss=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/101523] Huge number of combine attempts
Date: Wed, 20 Mar 2024 11:53:16 +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: 12.0
X-Bugzilla-Keywords: compile-time-hog, memory-hog
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: segher at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-101523-4-7CZpz6ZtuE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-101523-4@http.gcc.gnu.org/bugzilla/>
References: <bug-101523-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=3D101523

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andreas Krebbel from comment #1)
> This appears to be triggered by try_combine unnecessarily setting back the
> position by returning the i2 insn.
>=20
> When 866 is inserted into 973 866 still needs to be kept around for other
> users. So try_combine first merges the two sets into a parallel and
> immediately notices that this can't be recognized. Because none of the se=
ts
> is a trivial move it is split again into two separate insns. Although the
> new i2 pattern exactly matches the input i2 combine considers this to be a
> new insn and triggers all the scanning log link creation and eventually
> returns it what let's the combine start all over at 866.
>=20
> Due to that combine tries many of the substitutions more than 400x.
>=20
> Trying 866 -> 973:
>   866: r22393:DI=3Dr22391:DI+r22392:DI
>   973: r22499:DF=3Dr22498:DF*[r22393:DI]
>       REG_DEAD r22498:DF
> Failed to match this instruction:
> (parallel [
>         (set (reg:DF 22499)
>             (mult:DF (reg:DF 22498)
>                 (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ])
>                         (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64])=
))
>         (set (reg/f:DI 22393 [ _85087 ])
>             (plus:DI (reg/f:DI 22391 [ _85085 ])
>                 (reg:DI 22392 [ _85086 ])))
>     ])
> Failed to match this instruction:
> (parallel [
>         (set (reg:DF 22499)
>             (mult:DF (reg:DF 22498)
>                 (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ])
>                         (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64])=
))
>         (set (reg/f:DI 22393 [ _85087 ])
>             (plus:DI (reg/f:DI 22391 [ _85085 ])
>                 (reg:DI 22392 [ _85086 ])))
>     ])
> Successfully matched this instruction:
> (set (reg/f:DI 22393 [ _85087 ])
>     (plus:DI (reg/f:DI 22391 [ _85085 ])
>         (reg:DI 22392 [ _85086 ])))

So this is "unchanged", do we re-combine into it?

> Successfully matched this instruction:
> (set (reg:DF 22499)
>     (mult:DF (reg:DF 22498)
>         (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ])
>                 (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64])))

This one is changed.

> allowing combination of insns 866 and 973
> original costs 4 + 4 =3D 8
> replacement costs 4 + 4 =3D 8
> modifying insn i2   866: r22393:DI=3Dr22391:DI+r22392:DI
> deferring rescan insn with uid =3D 866.
> modifying insn i3   973: r22499:DF=3Dr22498:DF*[r22391:DI+r22392:DI]
>       REG_DEAD r22498:DF
> deferring rescan insn with uid =3D 973.

The change itself looks reasonable given costs, though maybe 2 -> 2
combinations should not trigger when the cost remains the same?  In
this case it definitely doesn't look profitable, does it?  Well,
in theory it might hide latency and the 2nd instruction can issue
at the same time as the first.=