[Bug tree-optimization/94962] New: Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[Bug tree-optimization/94962] New: Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[nemo@self-evident.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

            Bug ID: 94962
           Summary: Suboptimal AVX2 code for
                    _mm256_zextsi128_si256(_mm_set1_epi8(-1))
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nemo@self-evident.org
  Target Milestone: ---

Background: https://stackoverflow.com/q/61601902/

GCC emits an unnecessary "vmovdqa xmm0,xmm0" for the following code:

     __m256i mask()
    {
        return _mm256_zextsi128_si256(_mm_set1_epi8(-1));
    }

Live example on godbolt: https://gcc.godbolt.org/z/PbsQDR

I have found no way to avoid this except by resorting to inline asm.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #1 from Hongtao.liu <crazylht at gmail dot com> ---
redudant vmovdaq xmm0, xmm0 is generated by 
----
(insn:TI 7 6 14 2 (set (reg:V8SI 20 xmm0 [84])
        (vec_concat:V8SI (reg:V4SI 20 xmm0 [86])
            (const_vector:V4SI [
                    (const_int 0 [0]) repeated x4
                ])))
"/export/users2/liuhongt/install/gcc10_trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/avxintrin.h":770:20
5296 {avx_vec_concatv8si}
     (expr_list:REG_EQUIV (const_vector:V8SI [
                (const_int -1 [0xffffffffffffffff]) repeated x4
                (const_int 0 [0]) repeated x4
            ])
        (nil)))
-----

could be eliminated if src operand has same regno as dest operand.

---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 7a7ecd4be87..4ff4cf55f74 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -21123,6 +21123,9 @@
        }
     case 2:
     case 3:
+      if (register_operand (operands[1], <ssehalfvecmode>MODE)
+         && REGNO (operands[1]) == REGNO (operand[0]))
+       return "";
       switch (get_attr_mode (insn))
        {
        case MODE_V16SF:
---

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But such an instruction isn't always redundant, it really depends on what the
previous setter of the register did, whether the upper 128 bit of the 256-bit
register are already guaranteed to be zero or not.
Thus the #c1 patch looks incorrect to me, one would need peephole2s or some
combine patterns or target specific pass etc. to discover that at least for the
common cases; and it isn't something we model in the RTL patterns (what insns
guarantee which upper bits zero and what do not; and for some there can be
different choices even in the same define_insn, we could implement something
using widened registers and then there would be no guarantee etc.).

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #3 from Hongtao.liu <crazylht at gmail dot com> ---
You're right, from intel SDM: 
VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are
zeroed.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #4 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Jakub Jelinek from comment #2)
> But such an instruction isn't always redundant, it really depends on what
> the previous setter of the register did, whether the upper 128 bit of the
> 256-bit register are already guaranteed to be zero or not.
----
(define_insn "avx_vec_concat<mode>"
  [(set (match_operand:V_256_512 0 "register_operand" "=x,v,x,Yv")
        (vec_concat:V_256_512
          (match_operand:<ssehalfvecmode> 1 "nonimmediate_operand" "x,v,xm,vm")
          (match_operand:<ssehalfvecmode> 2 "nonimm_or_0_operand"
"xm,vm,C,C")))]

define_insn "*<extract_type>_vinsert<shuffletype><extract_suf>_0"
  [(set (match_operand:AVX512_VEC 0 "register_operand" "=v,x,Yv")
        (vec_merge:AVX512_VEC
          (match_operand:AVX512_VEC 1 "reg_or_0_operand" "v,C,C")
          (vec_duplicate:AVX512_VEC
                (match_operand:<ssequartermode> 2 "nonimmediate_operand"
"vm,xm,vm"))
          (match_operand:SI 3 "const_int_operand" "n,n,n")))]

----
Upper part already zeroed.

> Thus the #c1 patch looks incorrect to me, one would need peephole2s or some
> combine patterns or target specific pass etc. to discover that at least for
> the common cases; and it isn't something we model in the RTL patterns (what
> insns guarantee which upper bits zero and what do not; and for some there
> can be different choices even in the same define_insn, we could implement
> something using widened registers and then there would be no guarantee etc.).

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[nemo@self-evident.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #5 from Nemo <nemo@self-evident.org> ---
(In reply to Jakub Jelinek from comment #2)

I would be happy if GCC could just emit optimal code (single vcmpeqd
instruction) for this useful constant:

    _mm256_set_m128i(_mm_setzero_si128(), _mm_set1_epi8(-1))

aka.

    _mm256_inserti128_si256(_mm256_setzero_si256(), _mm_set1_epi8(-1), 0)


(The latter is just what GCC uses to implement _mm256_zextsi128_si256, if I am
reading the headers correctly.)

It's a minor thing, but I was a little surprised to find that none of the
compilers I know of are able to do this. At least, not with any input I tried.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #6 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Nemo from comment #5)
> (In reply to Jakub Jelinek from comment #2)
> 
> I would be happy if GCC could just emit optimal code (single vcmpeqd
> instruction) for this useful constant:
> 
>     _mm256_set_m128i(_mm_setzero_si128(), _mm_set1_epi8(-1))
> 
> aka.
> 
>     _mm256_inserti128_si256(_mm256_setzero_si256(), _mm_set1_epi8(-1), 0)
> 
> 
> (The latter is just what GCC uses to implement _mm256_zextsi128_si256, if I
> am reading the headers correctly.)
> 
> It's a minor thing, but I was a little surprised to find that none of the
> compilers I know of are able to do this. At least, not with any input I
> tried.

vmovdqa xmm0, xmm0 is not redundant here, it would clear up 128-256 bit which
is the meaning of `zext`.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[nemo@self-evident.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #7 from Nemo <nemo@self-evident.org> ---
(In reply to Hongtao.liu from comment #6)
>
> vmovdqa xmm0, xmm0 is not redundant here, it would clear up 128-256 bit
> which is the meaning of `zext`.

No, it is redundant because "vpcmpeqd xmm0, xmm0, xmm0" already zeroes out the
high lane of ymm0.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:a282f086ef26d90e9785e992cd09a0d118b24695

commit r13-2804-ga282f086ef26d90e9785e992cd09a0d118b24695
Author: Hu, Lin1 <lin1.hu@intel.com>
Date:   Tue Sep 13 16:28:54 2022 +0800

    i386: Optimize code generation of
__mm256_zextsi128_si256(__mm_set1_epi8(-1))

    gcc/ChangeLog:

            PR target/94962
            * config/i386/constraints.md (BH): New define_constraint.
            * config/i386/i386.cc (standard_sse_constant_p): Add return
            3/4 when operand matches new predicate.
            (standard_sse_constant_opcode): Add new alternative branch to
            return "vpcmpeqd".
            * config/i386/predicates.md
            (vector_all_ones_zero_extend_half_operand): New define_predicate.
            (vector_all_ones_zero_extend_quarter_operand): Ditto.
            * config/i386/sse.md: Add constraint to insn "mov<mode>_internal".

    gcc/testsuite/ChangeLog:

            PR target/94962
            * gcc.target/i386/avx256-unaligned-load-1.c: Modify test.
            * gcc.target/i386/avx256-unaligned-store-1.c: Ditto.
            * gcc.target/i386/avx256-unaligned-store-2.c: Ditto.
            * gcc.target/i386/avx256-unaligned-store-3.c: Ditto.
            * gcc.target/i386/pr94962-1.c: New test.
            * gcc.target/i386/pr94962-2.c: Ditto.
            * gcc.target/i386/pr94962-3.c: Ditto.
            * gcc.target/i386/pr94962-4.c: Ditto.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #9 from Hongtao.liu <crazylht at gmail dot com> ---
Fixed in trunk.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:9c9cf4f087f28dc3bf8dfa769380b3b58728a0f7

commit r13-2845-g9c9cf4f087f28dc3bf8dfa769380b3b58728a0f7
Author: Hu, Lin1 <lin1.hu@intel.com>
Date:   Mon Sep 26 10:15:08 2022 +0800

    testsuite: Fix up avx256-unaligned-store-3.c test.

    gcc/testsuite/ChangeLog:

            PR target/94962
            * gcc.target/i386/avx256-unaligned-store-3.c: Add -mno-avx512f