From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99890 invoked by alias); 24 Jul 2017 13:49:21 -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 98979 invoked by uid 89); 24 Jul 2017 13:49:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-ua0-f177.google.com Received: from mail-ua0-f177.google.com (HELO mail-ua0-f177.google.com) (209.85.217.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 24 Jul 2017 13:49:19 +0000 Received: by mail-ua0-f177.google.com with SMTP id q25so60009036uah.1 for ; Mon, 24 Jul 2017 06:49:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N76j7OJQ0BX2zeSMMbxcA6fAvpwqXy4JzDw9w9k7jog=; b=q/aNV3kyHLhIN+0JJPtili/wLEahVFTZRP2U8TdQ3oFUBSL34EbqVYeMeD5VuF3o9l q3m1QrkfPQj+kjYoUDsxvv2zSSeLzZyDB0dzFlAaD2hyRXVFgXgNvsi8V7ngFQ+rBv0v D3Cd3X4mCr2UMj7Muzm0z6b5e3ExVHSTOoLU7lkK+xe+eDU4d4CXb39p1gsnt1PbJCUM K0tjK7FEpQXRaPPdxMeTUbgekD9RO3CoG2oWmX6YQ9dlINoJn3MtsdF1aBlnepg5V1NJ E4wvew1a1jwBPPpWSzl3rPMwRG7AnN7FL26X83Ivrhl3PikqMFioaMNuEKsMHDk9+827 mmrQ== X-Gm-Message-State: AIVw113vyV1A4VnjkkFQ2+pCZERTCyxbmnrduo1alP+f/PIsYfWB0iM5 uh4E4ONXmGfYiEZu46JWyPN0mcnXnQ== X-Received: by 10.31.63.23 with SMTP id m23mr7469318vka.101.1500904157265; Mon, 24 Jul 2017 06:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.34.5 with HTTP; Mon, 24 Jul 2017 06:49:16 -0700 (PDT) In-Reply-To: References: From: "Bin.Cheng" Date: Mon, 24 Jul 2017 13:49:00 -0000 Message-ID: Subject: Re: [PATCH GCC][1/2]Feed bound computation to folder in loop split To: Marc Glisse Cc: gcc-patches List , Richard Biener , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg01426.txt.bz2 On Mon, Jul 24, 2017 at 1:16 PM, Marc Glisse wrote: > 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? Yes, it's doesn't matter. > >> 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. Thanks for elaboration. It's too late for next forwprop pass since we are in between loop optimizations and need the simplified code for niter analysis. Function compute_new_first_bound calls gimple_build several times, it's not likely to replace all gimple_build with gimple_simplify? Also gimple_simplify could return NULL_TREE, in which case I need to call gimple_build_assign again. At last, we don't have interface fold_seq similar to fold_stmt either. CCing Jakub if he found a solution. Thanks. Thanks, bin > > -- > Marc Glisse