From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23510 invoked by alias); 12 Oct 2015 13:11:29 -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 23487 invoked by uid 89); 12 Oct 2015 13:11:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-yk0-f172.google.com Received: from mail-yk0-f172.google.com (HELO mail-yk0-f172.google.com) (209.85.160.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 12 Oct 2015 13:11:27 +0000 Received: by ykoo7 with SMTP id o7so19588134yko.0 for ; Mon, 12 Oct 2015 06:11:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.13.207.131 with SMTP id r125mr19879248ywd.305.1444655485787; Mon, 12 Oct 2015 06:11:25 -0700 (PDT) Received: by 10.37.93.136 with HTTP; Mon, 12 Oct 2015 06:11:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 Oct 2015 13:11:00 -0000 Message-ID: Subject: Re: Move some bit and binary optimizations in simplify and match From: Richard Biener To: "Hurugalawadi, Naveen" Cc: "gcc-patches@gcc.gnu.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg01128.txt.bz2 On Mon, Oct 12, 2015 at 12:22 PM, Hurugalawadi, Naveen wrote: > Hi Richard, > > Thanks for your review and useful comments. > I will move the future optimization patterns with all the conditions > present in fold-const or builtins file as per your suggestions. > > Please find attached the patch as per your comments. > Please review the patch and let me know if any further modifications > are required. +/* Fold X + (X / CST) * -CST to X % CST. */ +(simplify + (plus (convert1? @0) (convert2? (mult (trunc_div @0 INTEGER_CST@1) INTEGER_CST@2))) + (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type)) + && wi::add (@1, @2) == 0) when you use convert? to mimic fold-const.c behavior you have to add && tree_nop_conversion_p (type, TREE_TYPE (@0)) note that in this case only both or no conversion can occur so please use convert? in both places. + (trunc_mod (convert @0) (convert @1)))) This applies to other uses of convert[12]?, too. As said for the above pattern fold-const.c also handled X + (X / A) * (-A) with A not being a constant. Unfortunately predicate syntax can't capture both -A and -CST but one can use (match (xdivamulminusa @X @A) (mult (trunc_div @X @A) (negate @X))) (match (xdivamulminusa @X @A) (mult (trunc_div @X INTEGER_CST@A) INTEGER_CST@0) (if (wi::add (@A, @0) == 0))) and then (simplify (plus (convert? @0) (convert? (xdivamulminusa @0 @1))) (if (...) (trunc_mod (convert @0) (convert @1)))) to avoid duplicating the pattern (though that might be more readable in this case...) +/* Fold (A & ~B) - (A & B) into (A ^ B) - B. */ +(simplify + (minus (bit_and:s @0 (bit_not @1)) (bit_and:s @0 @2)) + (if (! FLOAT_TYPE_P (type) + && wi::eq_p (@1, @2)) + (minus (bit_xor @0 @1) @1))) you can't simply use wi::eq_p on random trees. Same solution like above can be used (or pattern duplication). +/* Fold (a * (1 << b)) into (a << b) */ +(simplify + (mult:c (convert1? @0) (convert2? (lshift integer_onep@1 @2))) + (if (! FLOAT_TYPE_P (type)) + (lshift (convert @0) (convert @2)))) the conversion on @0 isn't interesting to capture, only that on the lshift is. +/* Fold (C1/X)*C2 into (C1*C2)/X. */ +(simplify + (mult (rdiv REAL_CST@0 @1) REAL_CST@2) + (with + { tree tem = const_binop (MULT_EXPR, type, @0, @2); } + (if (tem && FLOAT_TYPE_P (type) + && flag_associative_math) + (rdiv (mult @0 @2) @1)))) you comuted 'tem', so use it: (rdiv { tem; } @1)))) The FLOAT_TYPE_P check is redundant I think and the flag_associative_math check should be done before computing tem. +/* Simplify (X & ~Y) | (~X & Y) is X ^ Y. */ +(simplify + (bit_ior (bit_and:s @0 (bit_not @1)) (bit_and:s (bit_not @2) @3)) + (if (wi::eq_p (@0, @2) + && wi::eq_p (@1, @3)) + (bit_xor @0 @3))) See above for handling constants and using wi::eq_p. Looks like I really need to make 'match' handle these kind of things. +/* Simplify ~X & X as zero. */ +(simplify + (bit_and:c (convert? @0) (convert? (bit_not @0))) + (convert { build_zero_cst (TREE_TYPE (@0)); })) please simplify to { build_zero_cst (type); } directly. +/* (-A) * (-B) -> A * B */ +(simplify + (mult:c (convert? (negate @0)) (convert? (negate @1))) + (if ((GIMPLE && useless_type_conversion_p (type, TREE_TYPE (@0))) + || (GENERIC && type == TREE_TYPE (@0))) + (mult (convert @0) (convert @1)))) note that fold-const.c handled multiple ways of negation thus please use the existing negate_expr_p 'match' like (simplify (mult:c (convert? (negate @0)) (convert? negate_expr_p@1)) (if ... (mult (convert @0) (convert (negate @1))) also use tree_nop_conversion_p, not the GIMPLE/GENERIC variants. Thanks, Richard. > The last pattern has been removed due to the discussions over it > and a regression it caused. > ================================================ > +/* Fold X & (X ^ Y) as X & ~Y. */ > +(simplify > + (bit_and:c (convert? @0) (convert? (bit_xor:c @0 @1))) > + (bit_and (convert @0) (convert (bit_not @1)))) > ================================================ > > FAIL: gcc.dg/tree-ssa/vrp47.c scan-tree-dump-times vrp2 " & 1;" 0 > FAIL: gcc.dg/tree-ssa/vrp59.c scan-tree-dump-not vrp1 " & 3;" > > Thanks, > Naveen