https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069
--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Hongtao Liu from comment #5) > (In reply to Krzysztof Kanas from comment #4) > > I bisected the issue and it seems that commit > > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression. > > I guess the real guilty commit is > > commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7 > Author: Uros Bizjak <ubiz...@gmail.com> > Date: Thu May 25 19:40:26 2023 +0200 > > i386: Use 2x-wider modes when emulating QImode vector instructions > > Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI -> > V16HImode) > instructions when available. Currently, the compiler generates following > assembly for V16QImode multiplication (-mavx2): The patch is at: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619715.html As mentioned in Comment #3, it looks that VPERMQ is a problematic insn. This should be reflected in some cost function. Alternatively, we can simply change the first line in: + if ((qimode == V16QImode && !TARGET_AVX2) + || (qimode == V32QImode && !TARGET_AVX512BW) + /* There are no V64HImode instructions. */ + || qimode == V64QImode) + return false; to check "qimode == V16QImode && !TARGET_AVX512VL" to avoid VPERMQ: diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc index 4e16aedc5c1..450035ea9e6 100644 --- a/gcc/config/i386/i386-expand.cc +++ b/gcc/config/i386/i386-expand.cc @@ -24493,7 +24493,7 @@ ix86_expand_vecop_qihi2 (enum rtx_code code, rtx dest, rtx op1, rtx op2) bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT; bool uns_p = code != ASHIFTRT; - if ((qimode == V16QImode && !TARGET_AVX2) + if ((qimode == V16QImode && !TARGET_AVX512VL) || (qimode == V32QImode && (!TARGET_AVX512BW || !TARGET_EVEX512)) /* There are no V64HImode instructions. */ || qimode == V64QImode)
