> From: H.J. Lu <[email protected]> > Sent: Thursday, July 16, 2026 9:38 AM > > On Thu, Jul 16, 2026 at 9:30 AM H.J. Lu <[email protected]> wrote: > > > > On Wed, Jul 15, 2026 at 11:14 PM Dylan Rees <[email protected]> > wrote: > > > > > > 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 > > > > vector > 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=/export/users3/haochenj/src/gcc- > bisect/master/master/r17-2354/usr --enable-clocale=gnu --with-system-zlib - > -with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++,fortran -- > enable-cet --without-isl --enable-libmpx x86_64-linux --disable-bootstrap > > > > > > > > To reproduce: > > > > > > > > $ cd {build_dir}/gcc && make check > RUNTESTFLAGS="i386.exp=gcc.target/i386/pr124407-1.c -- > target_board='unix{-m64}'" > > > > $ cd {build_dir}/gcc && make check > RUNTESTFLAGS="i386.exp=gcc.target/i386/pr124407-1.c -- > target_board='unix{-m64\ -march=cascadelake}'" > > > > $ cd {build_dir}/gcc && make check > RUNTESTFLAGS="i386.exp=gcc.target/i386/pr81501-9b.c -- > target_board='unix{-m64}'" > > > > $ cd {build_dir}/gcc && make check > RUNTESTFLAGS="i386.exp=gcc.target/i386/pr81501-9b.c -- > target_board='unix{-m64\ -march=cascadelake}'" > > > > > > > > (Please directly reply to this email for question about this report.) > > > > (If you met problems with cascadelake related, disabling AVX512F in > command line might save that.) > > > > (However, please make sure that there is no potential problems with > AVX512.) > > > Hi Haochen, > > > > > > Thank you for pointing this out. Having reproduced all 3 failures I > > > realise 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 > order 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. > > There is no loop. The new code looks OK. > > > > For test 'gcc.target/i386/pr124407-1.c': > > > combine (rtl) step tries: > > > ''' > > > Trying 15, 13 -> 16: > > > 15: r113:V4SF=r115:V2SF#0 > > > REG_DEAD r115:V2SF > > > 13: r112:V4SF=const_vector > > > 16: r114:V4SF=r113:V4SF-r112:V4SF > > > REG_DEAD r113:V4SF > > > ''' > > > so it tried simplifying the subtract but target said no and seems to be > rejecting 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/pr > 124407-1.c":13:5 2466 {movv4sf_internal} > > > (expr_list:REG_DEAD (reg:V2SF 115 [ vD.5233 ]) > > > ''' > > > The issue is insn 15 is created as a paradoxical subreg before my patch > applies so the subtract can't be removed because it doesn't know what the > upper bits are. > > > Codegen appears better or the same, but as a result of the paradoxical > subreg the code looks a bit strange. > >
Hi H.J., I have not looked into it for all three cases. But whatever happened, should we at least change the (reg:V16QI 125) check? I did not get why we need to check exact number 125. Is it on purpose? I also have patches from my side breaks this by outputting another number. Thx, Haochen
