From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60988 invoked by alias); 13 Nov 2015 10:52:51 -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 60782 invoked by uid 89); 13 Nov 2015 10:52:50 -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-ig0-f170.google.com Received: from mail-ig0-f170.google.com (HELO mail-ig0-f170.google.com) (209.85.213.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 13 Nov 2015 10:52:48 +0000 Received: by igbxm8 with SMTP id xm8so12073766igb.1 for ; Fri, 13 Nov 2015 02:52:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.7.70 with SMTP id h6mr2458908iga.63.1447411965885; Fri, 13 Nov 2015 02:52:45 -0800 (PST) Received: by 10.36.209.7 with HTTP; Fri, 13 Nov 2015 02:52:45 -0800 (PST) In-Reply-To: References: <20151112154400.GE51435@msticlxl57.ims.intel.com> Date: Fri, 13 Nov 2015 10:52:00 -0000 Message-ID: Subject: Re: [PATCH] Fix ICE for boolean comparison From: Ilya Enkovich To: Richard Biener Cc: GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01655.txt.bz2 2015-11-13 13:38 GMT+03:00 Richard Biener : > On Thu, Nov 12, 2015 at 4:44 PM, Ilya Enkovich w= rote: >> Hi, >> >> Currently compiler may ICE when loaded boolean is compared with vector i= nvariant or another boolean value. This is because we don't detect mix of = bool and non-bool vectypes and incorrectly determine vectype for boolean lo= op invariant for comparison. This was fixed for COND_EXP before but also n= eeds to be fixed for comparison. This patch was bootstrapped and tested on= x86_64-unknown-linux-gnu. OK for trunk? > > Hmm, so this disables vectorization in these cases. Isn't this a > regression? Shouldn't we simply "materialize" > the non-bool vector from the boolean one say, with > > vec =3D boolvec ? {-1, -1 ... } : {0, 0, 0 ...} We may do this using patterns, but still should catch cases when patterns don't catch it. Patterns don't have vectypes computed and therefore may miss such cases. Thus stability fix is still valid. I don't think we have a compiler version which can vectorize simd-bool-comparison-2.cc, thus technically it is not a regression. There are also other similar cases, e.g. store of comparison result or use loaded boolean as a predicate. I was going to support vectorization for such cases later (seems I don't hit stage1 for them and not sure if it will be OK for stage3). Ilya > > ? > > Thanks, > Richard. > >> Thanks, >> Ilya