From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126375 invoked by alias); 30 Aug 2017 10:45:36 -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 125974 invoked by uid 89); 30 Aug 2017 10:45:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-23.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:Postfix, H*RU:Postfix, H*r:sk:smtprel, HX-HELO:sk:smtprel X-HELO: smtprelay.hostedemail.com Received: from smtprelay0050.hostedemail.com (HELO smtprelay.hostedemail.com) (216.40.44.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Aug 2017 10:45:24 +0000 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay06.hostedemail.com (Postfix) with ESMTP id 70F3618224D68; Wed, 30 Aug 2017 10:45:17 +0000 (UTC) X-Session-Marker: 6A62656E6973746F6E40756B322E6E6574 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,jon@beniston.com,:::,RULES_HIT:10:41:355:379:541:542:599:800:960:968:973:988:989:1155:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1535:1544:1587:1593:1594:1605:1711:1730:1747:1777:1792:2194:2199:2393:2559:2562:2693:2743:2899:3138:3139:3140:3141:3142:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4605:5007:6119:7903:8545:8603:8660:9121:10004:10848:11026:11232:11473:11658:11914:12043:12296:12438:12555:12663:12679:12740:12760:12895:13148:13161:13229:13230:13255:13439:13618:13869:14093:14096:14097:14180:14181:14721:21060:21080:21451:21627:30005:30012:30036:30054:30070,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:4,LUA_SUMMARY:none X-HE-Tag: bait02_8561ad386461f X-Filterd-Recvd-Size: 5405 Received: from LoftPC (cpc97974-croy24-2-0-cust112.19-2.cable.virginm.net [77.99.44.113]) (Authenticated sender: jbeniston@uk2.net) by omf03.hostedemail.com (Postfix) with ESMTPA; Wed, 30 Aug 2017 10:45:16 +0000 (UTC) From: "Jon Beniston" To: "'Richard Biener'" Cc: References: <015b01d31f6b$c3651620$4a2f4260$@beniston.com> <000001d31fd7$b239abb0$16ad0310$@beniston.com> In-Reply-To: Subject: RE: [RFC, vectorizer] Allow single element vector types for vector reduction operations Date: Wed, 30 Aug 2017 11:13:00 -0000 Message-ID: <004501d3217d$119d81c0$34d88540$@beniston.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-SW-Source: 2017-08/txt/msg01712.txt.bz2 Hi Richard, >> Ah, that's what I first tried, and mistakenly sent the patch against that. >> >> That did help the initial problem, but then I needed to add a lot of >> support for the V1SI type in the backend (which just duplicated SI >> patterns) and there are a few places where GCC seems to have sanity >> checks against vectors that are only one element wide. A dot product >> producing a scalar result seems natural. > >Where do you need V1SI types? The vectorizer should perform a SI extract >from V1SI here. You need to elaborate a bit here. After adding single element vector type support in the middle-end, at the tree level, V1SI vector types would be the result type for the dot product if the input operands were V2HI. During RTL expansion, if V1SImode is accepted in the TARGET_VECTOR_MODE_SUPPORTED_P hook, then V1SImode will be used after RTL expansion and V1SImode patterns are needed, although they are actually duplicates of SImode patterns. I have now removed V1SImode from TARGET_VECTOR_MODE_SUPPORTED_P, and they are turned into SI mode so there is no need for the V1SI patterns now. >> The vectorizer doesn't really support vector->scalar ops so V1SI >> feels more natural here. That is, your patch looks a bit ugly -- >> there's nothing wrong with V1SI vector types. I agree "there's nothing wrong with V1SI vector types" and the original patch was trying to let vector reduction operation accept V1SI vector types. However, if the only change was "<= 1" into "< 1" in get_vectype_for_scalar_type_and_size, then it will cause a GCC assertion failure in optab_for_tree_node for some shift operations. It seems all such failures come from: vect_pattern_recog_1:4185 optab = optab_for_tree_code (code, type_in, optab_default); The SUB_TYPE passed to optab_for_tree_code is "optab_default", however it is possible that vect_pattern_recog_1 will generate gimple containing shift operations, for example vect_recog_divmod_pattern will generate RSHIFT_EXPR, while shift operation requires sub_type to be not optab_default? gcc/optabs-tree.h: /* An extra flag to control optab_for_tree_code's behavior. This is needed to distinguish between machines with a vector shift that takes a scalar for the shift amount vs. machines that take a vector for the shift amount. */ enum optab_subtype { optab_default, optab_scalar, optab_vector }; It looks to me like the other call sites of optab_for_tree_code which are passing optab_default are mostly places where GCC is sure it is not a shift operation. Given TYPE_IN is returned from get_vectype_for_scalar_type, is it safe to simply pass optab_vector in vect_pattern_recog_1? I have verified the following middle-end fix also works for my port, it passed also x86-64 bootstrap and there is no regression in gcc/g++ regression. How is this new patch? gcc/ 2017-08-30 Jon Beniston * tree-vect-patterns.c (vect_pattern_recog_1): Pass optab_vector when calling optab_for_tree_code. * tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Allow single element vector types. diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c index cfdb72c..4b39cb6 100644 --- a/gcc/tree-vect-patterns.c +++ b/gcc/tree-vect-patterns.c @@ -4182,7 +4182,7 @@ vect_pattern_recog_1 (vect_recog_func *recog_func, code = CALL_EXPR; } - optab = optab_for_tree_code (code, type_in, optab_default); + optab = optab_for_tree_code (code, type_in, optab_vector); vec_mode = TYPE_MODE (type_in); if (!optab || (icode = optab_handler (optab, vec_mode)) == CODE_FOR_nothing 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 = mode_for_vector (inner_mode, size / nbytes); nunits = GET_MODE_SIZE (simd_mode) / nbytes; - if (nunits <= 1) + /* NOTE: nunits == 1 is allowed to support single element vector types. */ + if (nunits < 1) return NULL_TREE; vectype = build_vector_type (scalar_type, nunits);