https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120808
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2025-06-25
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. In this case we see at SLP time
<bb 2> [local count: 1073741824]:
_1 = *x_8(D);
_2 = *y_9(D);
_3 = *z_10(D);
_11 = .FMA (_1, _2, _3);
*x_8(D) = _11;
_4 = MEM[(double *)x_8(D) + 8B];
_5 = MEM[(double *)y_9(D) + 8B];
_6 = MEM[(double *)z_10(D) + 8B];
_13 = .FMS (_4, _5, _6);
MEM[(double *)x_8(D) + 8B] = _13;
and
t2.c:3:10: note: Build SLP for _11 = .FMA (_1, _2, _3);
t2.c:3:10: note: Build SLP for _13 = .FMS (_4, _5, _6);
t2.c:3:10: missed: Build SLP failed: different operation in stmt _13 = .FMS
(_4, _5, _6);
t2.c:3:10: missed: original stmt _11 = .FMA (_1, _2, _3);
we do not include .FMA/.FMS in the set of "two operator" handling operations.
That's "easy" to rectify for this particular case so you at least get
poor-mans handling. What's then missing is the SLP pattern FMADDSUB
processing because that's not handling .FMA/.FMS either.
So we'd get for now
vmovupd (%rdi), %xmm0
vmovupd (%rsi), %xmm2
vmovupd (%rdx), %xmm1
vmovapd %xmm0, %xmm3
vfmsub132pd %xmm2, %xmm1, %xmm3
vfmadd132pd %xmm2, %xmm1, %xmm0
vmovsd %xmm0, %xmm3, %xmm4
vmovupd %xmm4, (%rdi)
and hit PR81904. I have a patch for this part.
