[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5

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

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

--- Comment #46 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98

commit r13-2061-g5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Aug 16 00:18:51 2022 -0500

    vect: Don't allow vect_emulated_vector_p type in vectorizable_call
[PR106322]

    As PR106322 shows, in some cases for some vector type whose
    TYPE_MODE is a scalar integral mode instead of a vector mode,
    it's possible to obtain wrong target support information when
    querying with the scalar integral mode.  For example, for the
    test case in PR106322, on ppc64 32bit vectorizer gets vector
    type "vector(2) short unsigned int" for scalar type "short
    unsigned int", its mode is SImode instead of V2HImode.  The
    target support querying checks umul_highpart optab with SImode
    and considers it's supported, then vectorizer further generates
    .MULH IFN call for that vector type.  Unfortunately it's wrong
    to use SImode support for that vector type multiply highpart
    here.

    This patch is to teach vectorizable_call analysis not to allow
    vect_emulated_vector_p type for both vectype_in and vectype_out
    as Richi suggested.

            PR tree-optimization/106322

    gcc/ChangeLog:

            * tree-vect-stmts.cc (vectorizable_call): Don't allow
            vect_emulated_vector_p type for both vectype_in and vectype_out.

    gcc/testsuite/ChangeLog:

            * gcc.target/i386/pr106322.c: New test.
            * gcc.target/powerpc/pr106322.c: New test.