aboutsummaryrefslogtreecommitdiff
path: root/libjava
diff options
context:
space:
mode:
authorKewen Lin <linkw@linux.ibm.com>2022-08-16 00:18:51 -0500
committerKewen Lin <linkw@linux.ibm.com>2022-08-16 00:19:38 -0500
commit5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98 (patch)
tree16683c59b23c4afdd6ccc3b93f421b69779e830a /libjava
parenta2ff389099c325bc1244b1d72744a18c5fa6fda3 (diff)
downloadgcc-5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98.zip
gcc-5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98.tar.gz
gcc-5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98.tar.bz2
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.
Diffstat (limited to 'libjava')
0 files changed, 0 insertions, 0 deletions