https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126619
Roger Sayle <roger at nextmovesoftware dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed| |2026-08-03
CC| |roger at nextmovesoftware dot
com
--- Comment #1 from Roger Sayle <roger at nextmovesoftware dot com> ---
Many thanks for benchmarking, reporting this problem and reducing a testcase.
Yes, there's a serious regression with V4SF, not (intrinsically) in the RTL
expansion which uses the same insructions as before "unpcklps+unpcklps+movlhps"
but in the book-keeping/register allocation.
This is seen in the fabcd case for v4sf.
Before:
unpcklps %xmm3, %xmm2
unpcklps %xmm1, %xmm0
movlhps %xmm2, %xmm0
ret
After:
movd %xmm0, %eax
movd %eax, %xmm0
movd %xmm1, %eax
movd %eax, %xmm1
movd %xmm2, %eax
movd %eax, %xmm2
movd %xmm3, %eax
unpcklps %xmm1, %xmm0
movd %eax, %xmm3
unpcklps %xmm3, %xmm2
movlhps %xmm2, %xmm0
ret
I'm guessing there's a missing SF/V4SF case/variant in a define_insn that
exists for the corresponding SI/V4SI.
Investigating...
