From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67597 invoked by alias); 18 Sep 2015 12:22:26 -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 67588 invoked by uid 89); 18 Sep 2015 12:22:25 -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-f176.google.com Received: from mail-yk0-f176.google.com (HELO mail-yk0-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 18 Sep 2015 12:22:24 +0000 Received: by ykft14 with SMTP id t14so44786877ykf.0 for ; Fri, 18 Sep 2015 05:22:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.81.5 with SMTP id x5mr4266032ykx.82.1442578942617; Fri, 18 Sep 2015 05:22:22 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Fri, 18 Sep 2015 05:22:22 -0700 (PDT) In-Reply-To: References: <55D62076.8020105@redhat.com> <20150901130800.GA55610@msticlxl57.ims.intel.com> Date: Fri, 18 Sep 2015 12:29:00 -0000 Message-ID: Subject: Re: [RFC] Try vector as a new representation for vector masks From: Richard Biener To: Ilya Enkovich Cc: Jeff Law , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01399.txt.bz2 On Thu, Sep 3, 2015 at 3:57 PM, Ilya Enkovich wrote: > 2015-09-03 15:11 GMT+03:00 Richard Biener : >> On Thu, Sep 3, 2015 at 2:03 PM, Ilya Enkovich wrote: >>> Adding CCs. >>> >>> 2015-09-03 15:03 GMT+03:00 Ilya Enkovich : >>>> 2015-09-01 17:25 GMT+03:00 Richard Biener : >>>> >>>> Totally disabling old style vector comparison and bool pattern is a >>>> goal but doing hat would mean a lot of regressions for many targets. >>>> Do you want to it to be tried to estimate amount of changes required >>>> and reveal possible issues? What would be integration plan for these >>>> changes? Do you want to just introduce new vector in GIMPLE >>>> disabling bool patterns and then resolving vectorization regression on >>>> all targets or allow them live together with following target switch >>>> one by one from bool patterns with finally removing them? Not all >>>> targets are likely to be adopted fast I suppose. >> >> Well, the frontends already create vec_cond exprs I believe. So for >> bool patterns the vectorizer would have to do the same, but the >> comparison result in there would still use vec. Thus the scalar >> >> _Bool a = b < c; >> _Bool c = a || d; >> if (c) >> >> would become >> >> vec a = VEC_COND ; >> vec c = a | d; > > This should be identical to > > vec<_Bool> a = a < b; > vec<_Bool> c = a | d; > > where vec<_Bool> has VxSI mode. And we should prefer it in case target > supports vector comparison into vec, right? > >> >> when the target does not have vecs directly and otherwise >> vec directly (dropping the VEC_COND). >> >> Just the vector comparison inside the VEC_COND would always >> have vec type. > > I don't really understand what you mean by 'doesn't have vecs > dirrectly' here. Currently I have a hook to ask for a vec mode > and assume target doesn't support it in case it returns VOIDmode. But > in such case I have no mode to use for vec inside VEC_COND > either. I was thinking about targets not supporting generating vec (of whatever mode) from a comparison directly but only via a COND_EXPR. > In default implementation of the new target hook I always return > integer vector mode (to have default behavior similar to the current > one). It should allow me to use vec for conditions in all > vec_cond. But we'd need some other trigger for bool patterns to apply. > Probably check vec_cmp optab in check_bool_pattern and don't convert > in case comparison is supported by target? Or control it via > additional hook. Not sure if we are always talking about the same thing for "bool patterns". I'd remove bool patterns completely, IMHO they are not necessary at all. >> >> And the "bool patterns" I am talking about are those in >> tree-vect-patterns.c, not any targets instruction patterns. > > I refer to them also. BTW bool patterns also pull comparison into > vec_cond. Thus we cannot have SSA_NAME in vec_cond as a condition. I > think with vector comparisons in place we should allow SSA_NAME as > conditions in VEC_COND for better CSE. That should require new vcond > optabs though. I think we do allow this, just the vectorizer doesn't expect it. In the long run I want to get rid of the GENERIC exprs in both COND_EXPR and VEC_COND_EXPR. Just didn't have the time to do this... Richard. > Ilya > >> >> Richard. >> >>>> >>>> Ilya