From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121326 invoked by alias); 2 Jun 2015 17:34:01 -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 121309 invoked by uid 89); 2 Jun 2015 17:34:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPAM_BODY1,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:00 +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 F02F5B72CB; Tue, 2 Jun 2015 17:33:58 +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 t52HXw5X008398; Tue, 2 Jun 2015 13:33:58 -0400 Message-ID: <556DE906.1060201@redhat.com> Date: Tue, 02 Jun 2015 17:34: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 CC: 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/msg00225.txt.bz2 On 06/01/2015 05:07 AM, Richard Biener wrote: >> +(simplify >> + (cond @0 (convert @1) INTEGER_CST@2) >> + (if (INTEGRAL_TYPE_P (TREE_TYPE (@1)) >> + && COMPARISON_CLASS_P (@0) >> + && 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)))))) >> + >> +(simplify >> + (cond @0 INTEGER_CST@1 (convert @2)) >> + (if (INTEGRAL_TYPE_P (TREE_TYPE (@2)) >> + && COMPARISON_CLASS_P (@0) >> + && int_fits_type_p (@1, TREE_TYPE (@2)) >> + && ((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 (@2); tree otype = TREE_TYPE (@1); } >> + (convert:otype (cond:itype @0 (convert:itype @1) @2))))) > > Now this is a case where :c support on cond would make sense... Yea. The trick would be describing which operands can commute since COND_EXPR has 3 operands. I guess we could just define it in the obvious way for COND_EXPR and special case it wherever we need. in > theory the preprocessor would also be your friend here. Or we could > enhance the syntax to support multiple match patterns for the same > result, thus > > (simplify > (cond @0 (convert @1) INTEGER_CST@2) > (cond @0 INTEGER_CST@2 (convert @1)) > (if ... > > though that would require some extra markup to see where the list of matches > ends. user-defined predicates can be used for this already though > > (match (widening_cond @0 @1 @2) > (cond @0 (convert @1) INTEGER_CST@2)) > (match (widening_cond @0 @1 @2) > (cond @0 INTEGER_CST@2 (convert @1))) > (simplify > (widening_cond @0 @1 @2) > (if (... If you'd prefer this syntax, I'm happy to switch to it and simplify later if we gain :c support on the COND_EXPR. > > but the comments from Marc still holds in that you shouldn't rely > on @0 being GENERIC - you want a GIMPLE testcase as well for this, > sth like > > _Bool cond = 64 < mode_size[mode]; > return cond ? 64 : mode_size[mode]; Yea, I'll poke at that to generate some gimple tests. Not sure if I'll get another iteration out before heading on PTO or not. Thanks for the feedback, Jeff