From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7434 invoked by alias); 23 Sep 2015 18:44:14 -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 7420 invoked by uid 89); 23 Sep 2015 18:44:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 23 Sep 2015 18:44:12 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id D10BC8F315; Wed, 23 Sep 2015 18:44:10 +0000 (UTC) Received: from anchor.twiddle.net (vpn-225-68.phx2.redhat.com [10.3.225.68]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8NIiAM4023072; Wed, 23 Sep 2015 14:44:10 -0400 Subject: Re: [RFC] Try vector as a new representation for vector masks To: Richard Biener , Ilya Enkovich References: <55D62076.8020105@redhat.com> <20150901130800.GA55610@msticlxl57.ims.intel.com> ! Cc: Jeff Law , gcc-patches From: Richard Henderson X-Enigmail-Draft-Status: N1110 Message-ID: <5602F2F9.5090401@redhat.com> Date: Wed, 23 Sep 2015 18:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01789.txt.bz2 On 09/23/2015 06:53 AM, Richard Biener wrote: > I think independent improvements are > > 1) remove (most) of the bool patterns from the vectorizer > > 2) make VEC_COND_EXPR not have a GENERIC comparison embedded > > (same for COND_EXPR?) Careful. The reason that COND_EXPR have embedded comparisons is to handle flags registers. You can't separate the setting of the flags from the using of the flags on most targets, because there's only one flags register. The same is true for VEC_COND_EXPR with respect to MIPS. The base architecture has 8 floating-point comparison result flags, and the vector compare instructions are fixed to set fcc[0:width-1]. So again there's only one possible output location for the result of the compare. MIPS is going to present a problem if we attempt to generalize logical combinations of these vector, since one has to use several instructions (or one insn and pre-load constants into two registers) to get the fcc bits out into a form we can manipulate. r~