From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104537 invoked by alias); 24 Jul 2017 12:16:20 -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 103374 invoked by uid 89); 24 Jul 2017 12:16:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy= X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Jul 2017 12:16:17 +0000 Received: from stedding-dock.saclay.inria.fr ([193.55.177.248]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jul 2017 14:16:15 +0200 Date: Mon, 24 Jul 2017 12:16:00 -0000 From: Marc Glisse To: "Bin.Cheng" cc: gcc-patches List , Richard Biener Subject: Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2017-07/txt/msg01421.txt.bz2 On Mon, 24 Jul 2017, Bin.Cheng wrote: >> For _123, we have >> >> /* (A +- CST1) +- CST2 -> A + CST3 >> or >> /* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */ >> >> >> For _115, we have >> >> /* min (a, a + CST) -> a where CST is positive. */ >> /* min (a, a + CST) -> a + CST where CST is negative. */ >> (simplify >> (min:c @0 (plus@2 @0 INTEGER_CST@1)) >> (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))) >> (if (tree_int_cst_sgn (@1) > 0) >> @0 >> @2))) >> >> What is the type of all those SSA_NAMEs? > Hi, > From the debugging process, there are two issues preventing "(A +- > CST1) +- CST2 -> A + CST3" from being applied: > A) before we reach this pattern, there is pattern: > > /* A - B -> A + (-B) if B is easily negatable. */ > (simplify > (minus @0 negate_expr_p@1) > (if (!FIXED_POINT_TYPE_P (type)) > (plus @0 (negate @1)))) > > which is matched and returned in gimple_simplify_MINUS_EXPR. So does > pattern order matter here? That shouldn't be a problem, normally we always try to resimplify the result of the simplification, and the transformation should handle x+1+-1 just as well as x+1-1. Is that not happening? > B) When folding "_124 - 1" on the basis of existing stmts sequence > like "_124 = _197 + 1;". The corresponding gimple-match.c code is > like: [...] > But since definition of _197 isn't in current stmt sequence, call "o31 > = do_valueize (valueize, o31)" will return NULL. As a result, it's > not matched. Ah, yes, that problem... Jakub was having a very similar issue a few weeks ago, don't know if he found a solution. You could call gimple_simplify directly with a different valueization function if that's safe. Normally the simplification would wait until the next forwprop pass. -- Marc Glisse