https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Bug ID: 105275
Summary: 525.x264_r and 538.imagick_r regressed on x86_64 at
-O2 with PGO after r12-7319-g90d693bdc9d718
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
I can see x86_64 regressions of 525.x264_r and 538.imagick_r when
built with plain -O2 (so generic march/mtune) and profile guided
optimization (PGO), compared to GCC 11.
The performance drop of 525.x264_r is about 11% on znver3 and 10% on
Intel cascadelake. The performance drop of 538.imagick_r is about
6.4% on znver3. FWIW, I bisected both to commit
r12-7319-g90d693bdc9d718:
commit 90d693bdc9d71841f51d68826ffa5bd685d7f0bc
Author: Richard Biener <rguent...@suse.de>
Date: Fri Feb 18 14:32:14 2022 +0100
target/99881 - x86 vector cost of CTOR from integer regs
This uses the now passed SLP node to the vectorizer costing hook
to adjust vector construction costs for the cost of moving an
integer component from a GPR to a vector register when that's
required for building a vector from components. A cruical difference
here is whether the component is loaded from memory or extracted
from a vector register as in those cases no intermediate GPR is involved.
The pr99881.c testcase can be Un-XFAILed with this patch, the
pr91446.c testcase now produces scalar code which looks superior
to me so I've adjusted it as well.
2022-02-18 Richard Biener <rguent...@suse.de>
PR tree-optimization/104582
PR target/99881
* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost):
Cost GPR to vector register moves for integer vector construction.
With PGo+LTO, the 538.imagick_r regression on znver3 is small (less
than 3%), the 525.x264_r ones are smaller but visible (9.4% and 7.1%
on the two machines).
