Re: [r17-2354 Regression] FAIL: gcc.target/i386/pr81501-9b.c check-function-bodies foo on Linux/x86_64

On Wed, Jul 15, 2026 at 11:14=E2=80=AFPM Dylan Rees <[email protected]> wr=
ote:
>
> On Wed, Jul 15, 2026 at 02:22:30PM +0800, Haochen Jiang wrote:
> > On Linux/x86_64,
> >
> > 10f6223d833874199e17226fbb0c562b69a1e72f is the first bad commit
> > commit 10f6223d833874199e17226fbb0c562b69a1e72f
> > Author: Dylan Rees <[email protected]>
> > Date:   Mon Jul 13 09:57:18 2026 +0000
> >
> >     middle-end: Eliminate redundant scalar duplication at different vec=
tor widths
> >
> > caused
> >
> > FAIL: gcc.target/i386/pr124407-1.c scan-rtl-dump x86_cse "\\(const_int =
0 \\[0\\]\\) repeated x16"
> > FAIL: gcc.target/i386/pr124407-1.c scan-rtl-dump x86_cse "\\(set \\(reg=
:V16QI 125\\)"
> > FAIL: gcc.target/i386/pr81501-9b.c check-function-bodies foo
> >
> > with GCC configured with
> >
> > ../../gcc/configure --prefix=3D/export/users3/haochenj/src/gcc-bisect/m=
aster/master/r17-2354/usr --enable-clocale=3Dgnu --with-system-zlib --with-=
demangler-in-ld --with-fpmath=3Dsse --enable-languages=3Dc,c++,fortran --en=
able-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> >
> > To reproduce:
> >
> > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.targe=
t/i386/pr124407-1.c --target_board=3D'unix{-m64}'"
> > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.targe=
t/i386/pr124407-1.c --target_board=3D'unix{-m64\ -march=3Dcascadelake}'"
> > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.targe=
t/i386/pr81501-9b.c --target_board=3D'unix{-m64}'"
> > $ cd {build_dir}/gcc && make check RUNTESTFLAGS=3D"i386.exp=3Dgcc.targe=
t/i386/pr81501-9b.c --target_board=3D'unix{-m64\ -march=3Dcascadelake}'"
> >
> > (Please directly reply to this email for question about this report.)
> > (If you met problems with cascadelake related, disabling AVX512F in com=
mand line might save that.)
> > (However, please make sure that there is no potential problems with AVX=
512.)
> Hi Haochen,
>
> Thank you for pointing this out. Having reproduced all 3 failures I reali=
se I  was previously aware of them and was
> intending to inform the appropriate maintainers of these tests.
>
> For test 'gcc.target/i386/pr81501-9b.c':
> This seems to be an overconstrained check as my patch rearranges the orde=
r in a sensible way but there
> is a 'check-function-bodies' enforcing a certain structure.

Before:

foo:
.LFB7297:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
vpbroadcastb %edi, %zmm0
leaq var@TLSDESC(%rip), %rax
movq %rsp, %rbp
.cfi_def_cfa_register 6
pushq %rbx
andq $-64, %rsp
subq $64, %rsp
.cfi_offset 3, -24
movq %fs:0, %rdi
call *var@TLSCALL(%rax)
vmovdqa64 %zmm0, (%rsp)
addq %rax, %rdi
movq %rax, %rbx
vzeroupper
call func1@PLT
call func2@PLT
vmovdqa64 (%rsp), %zmm0
testl %eax, %eax
jne .L8
.L2:
movq sinkx@GOTPCREL(%rip), %rax
vmovdqa %xmm0, (%rax)
movq sinkz@GOTPCREL(%rip), %rax
vmovdqa64 %zmm0, (%rax)
movq sinky@GOTPCREL(%rip), %rax
vmovdqa %ymm0, (%rax)
movq %fs:(%rbx), %rax
vzeroupper
movq -8(%rbp), %rbx
leave
.cfi_remember_state
.cfi_def_cfa 7, 8
ret
.p2align 4,,10
.p2align 3
.L8:
.cfi_restore_state
vzeroupper
call func3@PLT
vmovdqa64 (%rsp), %zmm0
jmp .L2
.cfi_endproc

After:

pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
leaq var@TLSDESC(%rip), %rax
movq %rsp, %rbp
.cfi_def_cfa_register 6
pushq %r12
.cfi_offset 12, -24
movl %edi, %r12d
movq %fs:0, %rdi
pushq %rbx
andq $-64, %rsp
.cfi_offset 3, -32
call *var@TLSCALL(%rax)
addq %rax, %rdi
movq %rax, %rbx
call func1@PLT
call func2@PLT
testl %eax, %eax
jne .L8
.L2:
movq sinkx@GOTPCREL(%rip), %rax
vpbroadcastb %r12d, %zmm0
vmovdqa %xmm0, (%rax)
movq sinkz@GOTPCREL(%rip), %rax
vmovdqa64 %zmm0, (%rax)
movq sinky@GOTPCREL(%rip), %rax
vmovdqa %ymm0, (%rax)
movq %fs:(%rbx), %rax
vzeroupper
leaq -16(%rbp), %rsp
popq %rbx
popq %r12
popq %rbp
.cfi_remember_state
.cfi_def_cfa 7, 8
ret

"vpbroadcastb %r12d, %zmm0" is moved into the loop.

> For test 'gcc.target/i386/pr124407-1.c':
> combine (rtl) step tries:
> '''
> Trying 15, 13 -> 16:
>    15: r113:V4SF=3Dr115:V2SF#0
>       REG_DEAD r115:V2SF
>    13: r112:V4SF=3Dconst_vector
>    16: r114:V4SF=3Dr113:V4SF-r112:V4SF
>       REG_DEAD r113:V4SF
> '''
> so it tried simplifying the subtract but target said no and seems to be r=
ejecting the subreg:
> '''
> (insn 15 14 16 2 (set (reg:V4SF 113 [ vD.5233 ])
>         (subreg:V4SF (reg:V2SF 115 [ vD.5233 ]) 0)) "/opt/buildAgent/work=
/505bfdd4dad8af3d/gcc/testsuite/gcc.target/i386/pr124407-1.c":13:5 2466 {mo=
vv4sf_internal}
>      (expr_list:REG_DEAD (reg:V2SF 115 [ vD.5233 ])
> '''
> The issue is insn 15 is created as a paradoxical subreg before my patch a=
pplies so the subtract can't be removed because it doesn't know what the up=
per bits are.
> Codegen appears better or the same, but as a result of the paradoxical su=
breg the code looks a bit strange.



--=20
H.J.