[Bug target/126619] [17 Regression] Slowdown of s116 from TSVC on x86_64 since r17-2876-gf0bd50e8317926

roger at nextmovesoftware dot com via Gcc-bugs <[email protected]> Mon, 03 Aug 2026 20:56:38 +0000
Newsgroups gmane.comp.gcc.bugs
Message-ID <[email protected]/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D126619

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 testcas=
e.
Yes, there's a serious regression with V4SF, not (intrinsically) in the RTL
expansion which uses the same insructions as before "unpcklps+unpcklps+movl=
hps"
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...=