[Bug target/106577] [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx since r13-2006-ga56c1641e9d25e46

["cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

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

commit r13-4462-gb3237a2c6847993f92218b65f96ece9831a8bfb0
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 2 11:08:45 2022 +0100

    i386: Save/restore recog_data in ix86_vector_duplicate_value [PR106577]

    On Tue, Aug 16, 2022 at 09:14:06AM +0100, Richard Sandiford via Gcc-patches
wrote:
    > IMO the correct low-effort fix is to save and restore recog_data
    > in ix86_vector_duplicate_value.  It's a relatively big copy,
    > but the current code is pretty wasteful anyway (allocating at
    > least a new SET and INSN for every query).  Compared to the
    > overhead of doing that, a copy to and from the stack shouldn't
    > be too bad.

    The following patch does that.
    It isn't the first spot in the compiler that does that, not even the first
    spot in the i386 backend.
    In i386-expand.cc beyond these 2 recog_memoized calls there is one in
    expand_vselect, but I think it is unlikely we'd run into these issues
trying
    to expand new permutations from splitters.

    2022-12-02  Jakub Jelinek  <jakub@redhat.com>

            PR target/106577
            * config/i386/i386-expand.cc (ix86_vector_duplicate_value):
Save/restore
            recog_data around recog_memoized calls.

            * gcc.target/i386/pr106577.c: New test.