From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125742 invoked by alias); 11 Sep 2019 08:27:58 -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 125717 invoked by uid 89); 11 Sep 2019 08:27:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=HContent-Transfer-Encoding:8bit X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Sep 2019 08:27:56 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 74775B11B; Wed, 11 Sep 2019 08:27:54 +0000 (UTC) Subject: Re: [PATCH 3/5] Rewrite part of and_comparisons_1 into match.pd. To: gcc-patches@gcc.gnu.org Cc: Richard Biener , Li Jia He , Andrew Pinski , Jeff Law , Segher Boessenkool , wschmidt@linux.ibm.com, Martin Liska References: <1561615913-22109-1-git-send-email-helijia@linux.ibm.com> <6fb28248-5134-cec5-5045-45253e4d2eb0@redhat.com> <6d333ccf-9905-e929-c2dc-fc611ff929f1@linux.ibm.com> <845bc280-7bd6-509b-3830-4ebde50f1b20@linux.ibm.com> <4efa66d4-c04c-e5a6-18ff-2f4310d7f64d@suse.cz> <3b78e414-ff03-daa8-448f-4eaf766a2635@suse.cz> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <8e67d843-c37b-06cd-52ea-943c97d58a87@suse.cz> Date: Wed, 11 Sep 2019 08:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00716.txt.bz2 On 9/10/19 1:19 PM, Marc Glisse wrote: > (some quick comments, I didn't check in details) Thanks for them. > > +    (and:c (code1 @0 INTEGER_CST@1) (code2 @0 INTEGER_CST@2)) > [...] > +       (if (code1 == NE_EXPR && !val) (code2 @0 @2)))))))) > > How about > > (and:c (code1 @0 INTEGER_CST@1) (code2@3 @0 INTEGER_CST@2)) > [...] > (if (code1 == NE_EXPR && !val) @3))))))) > > instead? This is also a way to check how well the generator handles this, when @3 may not really exist (was in a gimple_cond). I like the changes. I applied them to all patterns in the patch set. > > (and:c (eq@3 @0 INTEGER_CST@1) (code2 @0 INTEGER_CST@2)) > > could be simplified to > > (and @3 (code2 @1 @2)) > > always (a trivial transform) and let the rest of the machinery fold code2 on constants and then and with a constant. This way you would only need to handle code1==NE_EXPR in the complicated transform, it might be slightly more readable. (I am not saying we absolutely have to do it this way, it is just a suggestion) That would be possible, I can experiment with that after the patch set is applied. The current patch is more or less direct transformation of what we have in gimple-fold.c. > > +   (and (code1:c @0 INTEGER_CST@1) (code2:c @0 INTEGER_CST@2)) > > Don't we canonicalize 3 < X to X > 3? That would make the :c unnecessary. Actually I don't remember how :c works on non-commutative operations (there was also :C I think). Dunno here, Richi? > > +      /* Chose the more restrictive of two < or <= comparisons.  */ > > Choose? Yep. Thank you, Martin >