From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2270 invoked by alias); 25 Aug 2015 21:26:47 -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 1368 invoked by uid 89); 25 Aug 2015 21:26:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham 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; Tue, 25 Aug 2015 21:26:46 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 14DFA341AC7; Tue, 25 Aug 2015 21:26:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-93.phx2.redhat.com [10.3.113.93]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7PLQhU3019612; Tue, 25 Aug 2015 17:26:43 -0400 Subject: Re: [Scalar masks 2/x] Use bool masks in if-conversion To: Ilya Enkovich , Richard Biener References: <20150817162544.GB12565@msticlxl57.ims.intel.com> <55D62076.8020105@redhat.com> Cc: GCC Patches From: Jeff Law Message-ID: <55DCDD93.7040800@redhat.com> Date: Tue, 25 Aug 2015 21:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01556.txt.bz2 On 08/21/2015 06:17 AM, Ilya Enkovich wrote: >> >> Hmm, I don't see how vector masks are more difficult to operate with. > > There are just no instructions for that but you have to pretend you > have to get code vectorized. > >> >>> Also according to vector ABI integer mask should be used for mask >>> operand in case of masked vector call. >> >> What ABI? The function signature of the intrinsics? How would that >> come into play here? > > Not intrinsics. I mean OpenMP vector functions which require integer > arg for a mask in case of 512-bit vector. That's what I assumed -- you can pass in a mask as an argument and it's supposed to be a simple integer, right? > >> >>> Current implementation of masked loads, masked stores and bool >>> patterns in vectorizer just reflect SSE4 and AVX. Can (and should) we >>> really call it a canonical representation for all targets? >> >> No idea - we'll revisit when another targets adds a similar capability. > > AVX-512 is such target. Current representation forces multiple scalar > mask -> vector mask and back transformations which are artificially > introduced by current bool patterns and are hard to optimize out. I'm a bit surprised they're so prevalent and hard to optimize away. ISTM PRE ought to handle this kind of thing with relative ease. >> Fact is GCC already copes with vector masks generated by vector compares >> just fine everywhere and I'd rather leave it as that. > > Nope. Currently vector mask is obtained from a vec_cond 0}, {-1 .. -1}>. AND and IOR on bools are also expressed via > additional vec_cond. I don't think vectorizer ever generates vector > comparison. > > And I wouldn't say it's fine 'everywhere' because there is a single > target utilizing them. Masked loads and stored for AVX-512 just don't > work now. And if we extend existing MASK_LOAD and MASK_STORE optabs to > 512-bit vector then we get an ugly inefficient code. The question is > where to fight with this inefficiency: in RTL or in GIMPLE. I want to > fight with it where it appears, i.e. in GIMPLE by preventing bool -> > int conversions applied everywhere even if target doesn't need it. You should expect pushback anytime target dependencies are added to gimple, even if it's stuff in the vectorizer, which is infested with target dependencies. > > If we don't want to support both types of masks in GIMPLE then it's > more reasonable to make bool -> int conversion in expand for targets > requiring it, rather than do it for everyone and then leave it to > target to transform it back and try to get rid of all those redundant > transformations. I'd give vector a chance to become a canonical > mask representation for that. Might be worth some experimentation. Jeff