https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122598
--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <[email protected]>: https://gcc.gnu.org/g:1c0897caa516bc564258266860e3b75054b9e78e commit r16-5486-g1c0897caa516bc564258266860e3b75054b9e78e Author: Jakub Jelinek <[email protected]> Date: Fri Nov 21 14:06:05 2025 +0100 i386: Remove cond_{ashl,lshr,ashr}v{64,16,32}qi expanders [PR122598] As mentioned in the PR, the COND_SH{L,R} internal fns are expanded without fallback, their expansion must succeed, and furthermore they don't differentiate between scalar and vector shift counts, so again both have to be supported. That is the case of the {ashl,lshr,ashr}v*[hsd]i patterns which use nonimmediate_or_const_vec_dup_operand predicate for the shift count, so if the argument isn't const vec dup, it can be always legitimized by loading into a vector register. This is not the case of the QImode element conditional vector shifts, there is no fallback for those and we emit individual element shifts in that case when not conditional and shift count is not a constant. So, I'm afraid we can't announce such an expander because then the vectorizer etc. count with it being fully available. As I've tried to show in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122598#c9 even without this pattern we can sometimes emit vgf2p8affineqb $0, .LC0(%rip), %ymm0, %ymm0{%k1} etc. instructions. 2025-11-21 Jakub Jelinek <[email protected]> PR target/122598 * config/i386/predicates.md (const_vec_dup_operand): Remove. * config/i386/sse.md (cond<<insn><mode> with VI1_AVX512VL iterator): Remove. * gcc.target/i386/pr122598.c: New test.
