[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #10 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:9c9cf4f087f28dc3bf8dfa769380b3b58728a0f7 commit r13-2845-g9c9cf4f087f28dc3bf8dfa769380b3b58728a0f7 Author: Hu, Lin1 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
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #9 from Hongtao.liu --- Fixed in trunk.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #8 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:a282f086ef26d90e9785e992cd09a0d118b24695 commit r13-2804-ga282f086ef26d90e9785e992cd09a0d118b24695 Author: Hu, Lin1 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_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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #7 from Nemo --- (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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #6 from Hongtao.liu --- (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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #5 from Nemo --- (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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #4 from Hongtao.liu --- (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" [(set (match_operand:V_256_512 0 "register_operand" "=x,v,x,Yv") (vec_concat:V_256_512 (match_operand: 1 "nonimmediate_operand" "x,v,xm,vm") (match_operand: 2 "nonimm_or_0_operand" "xm,vm,C,C")))] define_insn "*_vinsert_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: 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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #3 from Hongtao.liu --- 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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- 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))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1 from Hongtao.liu ---
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 [0x]) 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], MODE)
+ && REGNO (operands[1]) == REGNO (operand[0]))
+ return "";
switch (get_attr_mode (insn))
{
case MODE_V16SF:
---
