From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128993 invoked by alias); 30 Aug 2017 15:52:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 128894 invoked by uid 89); 30 Aug 2017 15:52:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*MI:46D4 X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Aug 2017 15:52:53 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7271EAD8A; Wed, 30 Aug 2017 15:52:51 +0000 (UTC) Date: Wed, 30 Aug 2017 16:32:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <00ba01d321a2$3fd81260$bf883720$@beniston.com> References: <015b01d31f6b$c3651620$4a2f4260$@beniston.com> <000001d31fd7$b239abb0$16ad0310$@beniston.com> <004501d3217d$119d81c0$34d88540$@beniston.com> <00ba01d321a2$3fd81260$bf883720$@beniston.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations To: Jon Beniston CC: gcc-patches@gcc.gnu.org From: Richard Biener Message-ID: <4B107F83-E41E-46D4-9529-970B7D073579@suse.de> X-SW-Source: 2017-08/txt/msg01736.txt.bz2 On August 30, 2017 5:11:24 PM GMT+02:00, Jon Beniston wr= ote: >Hi Richard, > >> I think the issue is that with TARGET_VECTOR_MODE_SUPPORTED_P false=20 >> for V1SI you'll get a SImode vector type and the >> >> if (VECTOR_BOOLEAN_TYPE_P (type_in) >> || VECTOR_MODE_P (TYPE_MODE (type_in))) >> >>check fails. Try changing that to || VECTOR_TYPE_P (type_in). >>The else path should be hopefully dead ... >> >>> It looks to me like the other call sites of optab_for_tree_code >which=20 >>> are passing optab_default are mostly places where GCC is sure it is=20 >>> not a shift operation. >>> Given TYPE_IN is returned from get_vectype_for_scalar_type, is it=20 >>> safe to simply pass optab_vector in vect_pattern_recog_1? >> >>I guess so. Can you also try the above? > >Changing VECTOR_MODE_P check into VECTOR_TYPE_P check also works for >me, I >verified the following patch could vectorize my dot product case and >there >is no regression on gcc tests on my port. > >Meanwhile x86-64 bootstraps OK and no regression on gcc/g++ test. > > Does this look OK? OK.=20 Thanks,=20 Richard.=20 > >gcc/ >2017-08-30 Jon Beniston > Richard Biener > >diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c >index cfdb72c..5ebeac2 100644 >--- a/gcc/tree-vect-patterns.c >+++ b/gcc/tree-vect-patterns.c >@@ -4150,7 +4150,7 @@ vect_pattern_recog_1 (vect_recog_func >*recog_func, > loop_vinfo =3D STMT_VINFO_LOOP_VINFO (stmt_info); >=20=20 > if (VECTOR_BOOLEAN_TYPE_P (type_in) >- || VECTOR_MODE_P (TYPE_MODE (type_in))) >+ || VECTOR_TYPE_P (type_in)) > { > /* No need to check target support (already checked by the pattern > recognition function). */ >diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c >index 013fb1f..fc62efb 100644 >--- a/gcc/tree-vect-stmts.c >+++ b/gcc/tree-vect-stmts.c >@@ -9098,7 +9098,8 @@ get_vectype_for_scalar_type_and_size (tree >scalar_type, unsigned size) > else > simd_mode =3D mode_for_vector (inner_mode, size / nbytes); > nunits =3D GET_MODE_SIZE (simd_mode) / nbytes; >- if (nunits <=3D 1) >+ /* NOTE: nunits =3D=3D 1 is allowed to support single element vector >types. >*/ >+ if (nunits < 1) > return NULL_TREE; >=20 > vectype =3D build_vector_type (scalar_type, nunits);