diff options
| author | Kewen Lin <linkw@linux.ibm.com> | 2022-08-16 00:18:51 -0500 |
|---|---|---|
| committer | Kewen Lin <linkw@linux.ibm.com> | 2022-08-16 00:19:38 -0500 |
| commit | 5239e2bd48fb1e6a1d1b06a1bac49bee0a742e98 (patch) | |
| tree | 16683c59b23c4afdd6ccc3b93f421b69779e830a /gcc/c/c-fold.c | |
| parent | a2ff389099c325bc1244b1d72744a18c5fa6fda3 (diff) | |
| download | gcc-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 'gcc/c/c-fold.c')
0 files changed, 0 insertions, 0 deletions