From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10429 invoked by alias); 20 Oct 2015 13:45:16 -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 10071 invoked by uid 89); 20 Oct 2015 13:45:16 -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-f174.google.com Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 20 Oct 2015 13:45:02 +0000 Received: by yknn9 with SMTP id n9so16621136ykn.0 for ; Tue, 20 Oct 2015 06:45:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.49.211 with SMTP id x202mr2507303ywx.147.1445348700422; Tue, 20 Oct 2015 06:45:00 -0700 (PDT) Received: by 10.37.117.136 with HTTP; Tue, 20 Oct 2015 06:45:00 -0700 (PDT) In-Reply-To: References: <20151008145948.GC63757@msticlxl57.ims.intel.com> Date: Tue, 20 Oct 2015 13:52: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-10/txt/msg01882.txt.bz2 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 > Shouldn't it be a patch independent from comparison vectorization series? As you like. >> >> Btw, I think you "mishandle" bool b = boolvar != 0; > > This should be handled fine. Statement will inherit a vectype of > 'boolvar' definition. If it's invariant - then yes, invariant boolean > statement case is not handled. But this is only because I supposed we > just shouldn't have such statements in a loop. If we may have them, > then using 'vector _Bool (VF)' type for that should be OK. > > Ilya > >> >> Richard. >>