https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126787
Bug ID: 126787
Summary: [15/16/17 Regression] i386: target clone on FMA4 emits
wrong fma instruction with egpr
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hongyuw at gcc dot gnu.org
Target Milestone: ---
Testcase:
typedef float f4;
__attribute__((__target__("avx,fma4")))
void smm_avx128_fma4(f4 * restrict c, const f4 * restrict a,
const f4 * restrict b, int m, int n, int k)
{
for (int j = 0; j < n; j++)
for (int l = 0; l < k; l++) {
f4 bl = b[l + j*k];
for (int i = 0; i < m; i++)
c[i + j*m] += a[i + l*m] * bl;
}
}
Compiled with -c -mapxf -O2 -ffast-math -ftree-vectorize -funroll-loops
--param max-unroll-times=4 -mprefer-avx128
Then assembler reports Error: no EVEX encoding for 'vfmaddps'
This is exposed when trying to bootstrap --with-arch=native on novalake since
gcc16, where apxf is auto invoked, and the libgfortran have such fma4 clone for
a matmul, then the bootstrap breaks. So on diamondrapids this could occur using
GCC15, but the extracted test fails at GCC14 as APX egpr is introduced then.
So we still need to gate out the FMA4/XOP vex ISAs that may use such target
clone and meets reg pressure issue. The Intel ISAs has either evex
promotion/counterpart which can directly be assembled in real hardware with
apx, while the leftover AMD isas doesn't.
