[Bug rtl-optimization/126638] New: [17 Regression] Compile time slowdown in var-tracking since r17-2277-g6d975812860304
"pheeck at gcc dot gnu.org via Gcc-bugs" <[email protected]> Tue, 04 Aug 2026 12:38:34 +0000
| Newsgroups | gmane.comp.gcc.bugs |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D126638
Bug ID: 126638
Summary: [17 Regression] Compile time slowdown in var-tracking
since r17-2277-g6d975812860304
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pheeck at gcc dot gnu.org
CC: law at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
Host: aarch64-gnu-linux
Target: aarch64-gnu-linux
Created attachment 65239
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D65239&action=3Dedit
The smaller testcase from pr39326, on which this slowdown occurs
This slowdown doesn't seem that interesting to me, but I wanted to let more
experienced people know about it. It certainly would be nice to recover the
lost compile time but it is only 20% on a testcase that IIUC comes from
source-to-source compilation of an SPL program (I've not heard about the SPL
language nor was I able to find any information about it). Therefore, this
seems like a minor issue to me, but I might be wrong.
----
Compilation of the smaller testcase from pr39326 with -O1 -g on Neoverse N1
machines slowed down by ~20% recently. I'm attaching the testcase to this
report. Here's a graph showing the slowdown:
https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=3D686.621.8
Here is -ftime-report of a commit before the slowdown and after the slowdow=
n.=20
I removed lines with times under a second for brevity. It looks like the e=
xtra
time is spent in var-tracking.
r17-2271-ge5af677005c7ab:
Time variable wall GGC
phase opt and generate : 70.85 (100%) 254M ( 93%)
callgraph functions expansion : 65.46 ( 92%) 223M ( 82%)
callgraph ipa passes : 5.31 ( 7%) 9785k ( 4%)
alias stmt walking : 15.95 ( 22%) 2454k ( 1%)
tree DSE : 4.93 ( 7%) 0 ( 0%)
tree loop invariant motion : 2.79 ( 4%) 3062k ( 1%)
integrated RA : 3.24 ( 5%) 28M ( 11%)
reload CSE regs : 2.05 ( 3%) 1827k ( 1%)
variable tracking : 2.00 ( 3%) 7839k ( 3%)
var-tracking dataflow : 17.19 ( 24%) 1347k ( 0%)
var-tracking emit : 15.72 ( 22%) 1583k ( 1%)
TOTAL : 71.00 272M
r17-2297-g1f949c2f1ab60a:
Time variable wall GGC
phase opt and generate : 86.72 (100%) 256M ( 93%)
callgraph functions expansion : 81.29 ( 94%) 225M ( 82%)
callgraph ipa passes : 5.35 ( 6%) 9785k ( 3%)
alias stmt walking : 16.06 ( 18%) 2454k ( 1%)
tree DSE : 4.96 ( 6%) 0 ( 0%)
tree loop invariant motion : 2.79 ( 3%) 3062k ( 1%)
integrated RA : 3.28 ( 4%) 28M ( 11%)
reload CSE regs : 1.96 ( 2%) 1827k ( 1%)
variable tracking : 1.94 ( 2%) 7819k ( 3%)
var-tracking dataflow : 26.27 ( 30%) 1666k ( 1%)
var-tracking emit : 22.35 ( 26%) 1838k ( 1%)
TOTAL : 86.88 274M
I bisected this to r17-2277-g6d975812860304
commit 6d97581286030449420dc4ee79612dd256067e2c
Author: Jovan Dmitrovic <[email protected]>
AuthorDate: Thu Jul 9 07:31:17 2026 -0600
Commit: Jeff Law <[email protected]>
CommitDate: Thu Jul 9 07:31:54 2026 -0600
ivopts: Set register pressure cost to zero if there are enough register=
s.
In function ivopts_estimate_reg_pressure, return zero if there are
enough registers available so that spilling is not necessary.
gcc/ChangeLog:
* tree-ssa-loop-ivopts.cc (ivopts_estimate_reg_pressure):
Return zero if there are enough registers to store new
invariants and induction variables.
Suggested-by: Richard Biener <[email protected]>
Signed-off-by: Jovan Dmitrovi=C4=87 <[email protected]>
Signed-off-by: Djordje Todorovi=C4=87 <[email protected]>
Signed-off-by: Chao-Ying Fu <[email protected]>
Signed-off-by: Radosav Kruni=C4=87 <[email protected]>
I'm Ccing only Richard and Jeff, since the other people mentioned by the co=
mmit
don't have a gcc.gnu.org mail. Bugzilla won't let me Cc them.=