From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115452 invoked by alias); 27 Jul 2015 08:48: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 115435 invoked by uid 89); 27 Jul 2015 08:48:47 -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-f177.google.com Received: from mail-ig0-f177.google.com (HELO mail-ig0-f177.google.com) (209.85.213.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 27 Jul 2015 08:48:46 +0000 Received: by igk11 with SMTP id 11so52500754igk.1 for ; Mon, 27 Jul 2015 01:48:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.110.72 with SMTP id hy8mr14495495igb.36.1437986924135; Mon, 27 Jul 2015 01:48:44 -0700 (PDT) Received: by 10.107.142.7 with HTTP; Mon, 27 Jul 2015 01:48:44 -0700 (PDT) In-Reply-To: <55B28DCB.2080404@redhat.com> References: <559F5D7B.6070208@redhat.com> <55B148AB.6010103@redhat.com> <55B28DCB.2080404@redhat.com> Date: Mon, 27 Jul 2015 09:04:00 -0000 Message-ID: Subject: Re: [PATCH] Simple optimization for MASK_STORE. From: Richard Biener To: Jeff Law Cc: Yuri Rumyantsev , gcc-patches , Igor Zamyatin Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg02217.txt.bz2 On Fri, Jul 24, 2015 at 9:11 PM, Jeff Law wrote: > On 07/24/2015 03:16 AM, Richard Biener wrote: >>> >>> Is there any rationale given anywhere for the transformation into >>> conditional expressions? ie, is there any reason why we can't have a >>> GIMPLE_COND where the expression is a vector condition? >> >> >> No rationale for equality compare which would have the semantic of >> having all elements equal or not equal. But you can't define a sensible >> ordering (that HW implements) for other compare operators and you >> obviously need a single boolean result, not a vector of element comparison >> results. > > Right. EQ/NE only as others just don't have any real meaning. > > >> I've already replied that I'm fine allowing ==/!= whole-vector compares. >> But one needs to check whether expansion does anything sensible >> with them (either expand to integer subreg compares or add optabs >> for the compares). > > Agreed, EQ/NE for whole vector compares only would be fine for me too under > the same conditions. Btw, you can already do this on GIMPLE by doing TImode vec_as_int = VIEW_CONVERT_EXPR (vec_2); if (vec_as_int == 0) ... which is what the RTL will look like in the end. So not sure if making this higher-level in GIMPLE is good or required. Richard. > jeff