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 F2C3B3857BA4; Wed,  4 Oct 2023 06:46:52 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2C3B3857BA4
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1696402012;
	bh=FstjC+ndyqrpELP3CiolB3APFjO7KkP6S6MADfNTOC8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=c69K9en/yQtAym9psBkXKaD16sJOSvRXXel/2j3cy/DODKSV53tMPL9l2dU4j2Ccq
	 Ghutm+O+DBpbVVmnKtyLlvCPuRlNYORt3SlgHxVRFEwRhv71l+hLCjeCWn64yYvrmU
	 QnEEj751N+A2MWJLyPQcLmrE7AhXIbPrO0foBMtU=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/111600] [14 Regression] RISC-V bootstrap time regression
Date: Wed, 04 Oct 2023 06:46: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: 14.0
X-Bugzilla-Keywords: compile-time-hog, needs-bisection
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: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 14.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-111600-4-kyfbYYydGQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-111600-4@http.gcc.gnu.org/bugzilla/>
References: <bug-111600-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=3D111600

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think despite looking at the total size of the files it would be nice to =
see
if some of the large functions take a lot of compile-time (and where) and s=
ee
whether some more intelligent code emission helps.  Like I pointed out stuff
like

insn_code
maybe_code_for_pred_indexed_load (int arg0, machine_mode arg1, machine_mode
arg2)
{
  if (arg0 =3D=3D 84
      && arg1 =3D=3D E_RVVMF8x2QImode
      && arg2 =3D=3D E_RVVMF8QImode)
    return CODE_FOR_pred_indexed_oloadrvvmf8x2qirvvmf8qi;
  if (arg0 =3D=3D 85
      && arg1 =3D=3D E_RVVMF8x2QImode
      && arg2 =3D=3D E_RVVMF8QImode)
    return CODE_FOR_pred_indexed_uloadrvvmf8x2qirvvmf8qi;
  if (arg0 =3D=3D 84
      && arg1 =3D=3D E_RVVMF8x3QImode
      && arg2 =3D=3D E_RVVMF8QImode)
    return CODE_FOR_pred_indexed_oloadrvvmf8x3qirvvmf8qi;
  if (arg0 =3D=3D 85
      && arg1 =3D=3D E_RVVMF8x3QImode
      && arg2 =3D=3D E_RVVMF8QImode)
...

that requires GCC to do a lot of jump threading to arrive at essentially
nested switches or a fancy lookup table (combining all args) to get this
to a point where it also behaves in a sane way at runtime (the above at -O0
would also execute very slowly).=