From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122833 invoked by alias); 2 Jun 2015 17:34: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 122823 invoked by uid 89); 2 Jun 2015 17:34:46 -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,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Tue, 02 Jun 2015 17:34:46 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id D636B2B785A; Tue, 2 Jun 2015 17:34:44 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-154.phx2.redhat.com [10.3.113.154]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t52HYiMK008663; Tue, 2 Jun 2015 13:34:44 -0400 Message-ID: <556DE934.9050605@redhat.com> Date: Tue, 02 Jun 2015 17:35:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Biener , gcc-patches Subject: Re: [RFA] Factor conversion out of COND_EXPR using match.pd pattern References: <55693B23.4000007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00226.txt.bz2 On 06/01/2015 04:55 AM, Richard Biener wrote: > On Sat, May 30, 2015 at 11:11 AM, Marc Glisse wrote: >> (only commenting on the technique, not on the transformation itself) >> >>> +(simplify >>> + (cond @0 (convert @1) INTEGER_CST@2) >>> + (if (INTEGRAL_TYPE_P (TREE_TYPE (@1)) >>> + && COMPARISON_CLASS_P (@0) >> >> >> If you add COMPARISON_CLASS_P to define_predicates, you could write: >> (cond COMPARISON_CLASS_P@0 (convert @1) INTEGER_CST@2) > > But that would fail to match on GIMPLE, so I don't like either variant > as Jeffs relies on the awkward fact that on GIMPLE cond expr conditions > are GENERIC and yours wouldn't work. > > That said - for this kind of patterns testcases that exercise the patterns > on GIMPLE would be very appreciated. OK. I'll see if I can build a testcase to exercise this in gimple. If that's not possible would you prefer the pattern be restricted to generic just to be safe? > >> or maybe use a for loop on comparisons, which would give names to >> TREE_OPERAND (@0, *). This should even handle the operand_equal_p >> alternative: >> >> (cond (cmp:c@0 @1 @2) (convert @1) INTEGER_CST@2) > > Yes, that would be my reference. OK. easily done. > >>> + && int_fits_type_p (@2, TREE_TYPE (@1)) >>> + && ((operand_equal_p (TREE_OPERAND (@0, 0), @2, 0) >>> + && operand_equal_p (TREE_OPERAND (@0, 1), @1, 0)) >>> + || (operand_equal_p (TREE_OPERAND (@0, 0), @1, 0) >>> + && operand_equal_p (TREE_OPERAND (@0, 1), @2, 0)))) >>> + (with { tree itype = TREE_TYPE (@1); tree otype = TREE_TYPE (@2); } >>> + (convert:otype (cond:itype @0 @1 (convert:itype @2)))))) >> >> >> This should be enough, no need to specify the outer type >> (convert (cond:itype @0 @1 (convert:itype @2)))))) > > Yes. > >> I believe we should not have to write cond:itype here, cond should be made >> to use the type of its second argument instead of the first one, by default >> (expr::gen_transform already has a few special cases). > > Indeed. Patch welcome (I'd have expected it already works...) One of them is needed, but I can't recall which :-) I'll pull them to generate the failure I'd run into and simplify appropriately and explain whichever is remaining. jeff