https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Bug ID: 106293
Summary: 456.hmmer at -Ofast -march=native regressed by 19% on
zen2 and zen3 in July 2022
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
The benchmark 456.hmmer from SPECINT 2006 suite has regressed on zen2 when
compiled with -Ofast -march=native, with or without LTO. See:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=301.180.0
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=289.180.0
On zen3, LNT only reported a similar regression with LTO:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=476.180.0
There may be some effect also on the Kabylake:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=2.180.0
On Zen2 (with LTO), I have manually bisected the regression to:
d2a898666609452ef79a14feae1cadc3538e4b45 is the first bad commit
commit d2a898666609452ef79a14feae1cadc3538e4b45
Author: Richard Biener <rguent...@suse.de>
Date: Tue Jun 21 16:17:58 2022 +0200
Put virtual operands into loop-closed SSA
When attempting to manually update SSA form after high-level loop
transforms such as loop versioning it is helpful when the loop-closed
SSA form includes virtual operands. While we have the special
rewrite_virtuals_into_loop_closed_ssa function that doesn't
presently scale, invoking update_ssa by itself. So the following
makes the regular loop-closed SSA form also cover virtual operands.
For users of loop_version this allows to use cheaper
TODO_update_ssa_no_phi, skipping dominance frontier compute
(for the whole function) and iterated dominance frontiers for each
copied def.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
