From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128779 invoked by alias); 9 Nov 2015 14:26:46 -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 128761 invoked by uid 89); 9 Nov 2015 14:26:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f181.google.com Received: from mail-yk0-f181.google.com (HELO mail-yk0-f181.google.com) (209.85.160.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 09 Nov 2015 14:26:45 +0000 Received: by ykdv3 with SMTP id v3so176593845ykd.0 for ; Mon, 09 Nov 2015 06:26:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.13.210.4 with SMTP id u4mr23944921ywd.68.1447079203323; Mon, 09 Nov 2015 06:26:43 -0800 (PST) Received: by 10.37.93.11 with HTTP; Mon, 9 Nov 2015 06:26:43 -0800 (PST) In-Reply-To: References: <20151008145948.GC63757@msticlxl57.ims.intel.com> Date: Mon, 09 Nov 2015 14:26:00 -0000 Message-ID: Subject: Re: [vec-cmp, patch 2/6] Vectorization factor computation From: Richard Biener To: Ilya Enkovich Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00968.txt.bz2 On Mon, Nov 9, 2015 at 2:54 PM, Ilya Enkovich wrote: > 2015-10-20 16:45 GMT+03:00 Richard Biener : >> On Wed, Oct 14, 2015 at 1:21 PM, Ilya Enkovich wrote: >>> 2015-10-13 16:37 GMT+03:00 Richard Biener : >>>> On Thu, Oct 8, 2015 at 4:59 PM, Ilya Enkovich wrote: >>>>> Hi, >>>>> >>>>> This patch handles statements with boolean result in vectorization factor computation. For comparison its operands type is used instead of restult type to compute VF. Other boolean statements are ignored for VF. >>>>> >>>>> Vectype for comparison is computed using type of compared values. Computed type is propagated into other boolean operations. >>>> >>>> This feels rather ad-hoc, mixing up the existing way of computing >>>> vector type and VF. I'd rather have turned the whole >>>> vector type computation around to the scheme working on the operands >>>> rather than on the lhs and then searching >>>> for smaller/larger types on the rhs'. >>>> >>>> I know this is a tricky function (heh, but you make it even worse...). >>>> And it needs a helper with knowledge about operations >>>> so one can compute the result vector type for an operation on its >>>> operands. The seeds should be PHIs (handled like now) >>>> and loads, and yes, externals need special handling. >>>> >>>> Ideally we'd do things in two stages, first compute vector types in a >>>> less constrained manner (not forcing a single vector size) >>>> and then in a 2nd run promote to a common size also computing the VF to do that. >>> >>> This sounds like a refactoring, not a functional change, right? Also I >>> don't see a reason to analyze DF to compute vectypes if we promote it >>> to a single vector size anyway. For booleans we have to do it because >>> boolean vectors of the same size may have different number of >>> elements. What is the reason to do it for other types? >> >> For conversions and operators which support different sized operands > > That's what we handle in vector patterns and use some helper functions > to determine vectypes there. Looks like this refactoring would affects > patterns significantly. Probably compute vectypes before searching for > patterns? > >> >>> Shouldn't it be a patch independent from comparison vectorization series? >> >> As you like. > > I'd like to move on with vector comparison and consider VF computation > refactoring when it's stabilized. This patch is the last one (except > target ones) not approved in all vector comparison related series. > Would it be OK to go on with it in a current shape? Yes. Thanks, Richard. > Thanks, > Ilya