From patchwork Sat Oct 8 19:38:30 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kugan Vivekanandarajah X-Patchwork-Id: 77404 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp680622qge; Sat, 8 Oct 2016 12:39:01 -0700 (PDT) X-Received: by 10.66.221.97 with SMTP id qd1mr31306019pac.120.1475955541836; Sat, 08 Oct 2016 12:39:01 -0700 (PDT) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id b3si22514025pav.115.2016.10.08.12.39.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Oct 2016 12:39:01 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-return-438026-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-438026-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-438026-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; q=dns; s=default; b=ujpU8hnSV14SW2S7C OSrF+L8gaRisKtWyCpVVpEgOqYAHryRyAkOTnWjQTGPR9kzeLY/ssIEmw5O6Fxsn T1j0VbVyDc9aVZDcQoTqb4i5UET1kIMlxX2CYT6Vk1J2XlqyagRO51yq9TmrThrP NoOY+xXwS3O4h79RMAL5CZ6gh0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type; s=default; bh=PO/UTrvJypVJ8fSmqioo2uL Xuh8=; b=rLYi9AL3uB6Try90qplXwf9xG0cZ5+b7a5ggI0MM8LWf+izDZdfBUxg YpbUBwvZ4MzxOtdldnEgYVeUzHqL4mgueFGUK5PNyCLqG6wlKNds8Il6a0WV3DCE dIJ8A/zMD+AbPLFfrFPfu6ECw4webTM1pPmVWGJJwYWiG4HMAq8Y= Received: (qmail 101174 invoked by alias); 8 Oct 2016 19:38:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 101160 invoked by uid 89); 8 Oct 2016 19:38:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=UD:msg00413.html, msg00413html, msg00413.html, UD:evrp6.c X-HELO: mail-pa0-f43.google.com Received: from mail-pa0-f43.google.com (HELO mail-pa0-f43.google.com) (209.85.220.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 08 Oct 2016 19:38:36 +0000 Received: by mail-pa0-f43.google.com with SMTP id rz1so35303216pab.1 for ; Sat, 08 Oct 2016 12:38:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=MX/SCnmX8d67648ks+ZbRhPR+TBXqi0Xv/0Q95IKt5Q=; b=jiVL/lIejdEszGeYydz4QQ2Clxq3X9anuLfpf5ePAGkcCQHCW0JfKqLEKjdHonKUVQ nu864y9tfvMHR+dJ+lneScluFlNd8TlTOfLz+hNAFbv+O5JL+j36KLWynO3LSr2TukeS Pa5e1CfQMtl0iDtJBfY9edDY6c9PWeOXSrEW9hMAaVfRtEm2W5r+C9ephOOmK1/5lZfA HVx7HXYbh4yMLspFS+V6nyfF3UHdr67YzmosXao9wnw+97ubBVZe1us3cdu0rUzrj0Ff rKrX94q2PnKl81+ZdTRhhjSUP4wO/3n1C7pN8FXp90J0UhkUbZVwXkVi3X3b+W0O6FpJ 8Bmw== X-Gm-Message-State: AA6/9RmDrTndrQ5uaVkeoDIH8narcIAq+OzbEfCpA4oHRE+df4EixWXXjW5TnIrrSr/jF4QO X-Received: by 10.67.10.14 with SMTP id dw14mr41148443pad.165.1475955514527; Sat, 08 Oct 2016 12:38:34 -0700 (PDT) Received: from [10.1.1.7] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id 141sm19953212pfz.93.2016.10.08.12.38.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Oct 2016 12:38:33 -0700 (PDT) Subject: Re: [RFC][VRP] Improve intersect_ranges To: Richard Biener References: <76edd771-749d-f85f-2d0e-84e714abb78e@linaro.org> Cc: "gcc-patches@gcc.gnu.org" From: kugan Message-ID: <881b2805-15ec-ad68-96a5-e2debd2fb850@linaro.org> Date: Sun, 9 Oct 2016 06:38:30 +1100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: X-IsSubscribed: yes Hi Richard, Thanks for the review. On 07/10/16 20:11, Richard Biener wrote: > On Fri, Oct 7, 2016 at 12:00 AM, kugan > wrote: >> Hi, >> >> In vrp intersect_ranges, Richard recently changed it to create integer value >> ranges when it is integer singleton. >> >> Maybe we should do the same when the other range is a complex ranges with >> SSA_NAME (like [x+2, +INF])? >> >> Attached patch tries to do this. There are cases where it will be beneficial >> as the testcase in the patch. (For this testcase to work with Early VRP, we >> need the patch posted at >> https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00413.html) >> >> Bootstrapped and regression tested on x86_64-linux-gnu with no new >> regressions. > > This is not clearly a win, in fact it can completely lose an ASSERT_EXPR > because there is no way to add its effect back as an equivalence. The > current choice of always using the "left" keeps the ASSERT_EXPR range > and is able to record the other range via an equivalence. How about changing the order in Early VRP when we are dealing with the same SSA_NAME in inner and outer scope. Here is a patch that does this. Is this OK if no new regressions? Thanks, Kugan > My thought on this was that we need to separate "ranges" and associated > SSA names so we can introduce new ranges w/o the need for an SSA name > (and thus we can create an equivalence to the ASSERT_EXPR range). > IIRC I started on this at some point but never finished it ... > > Richard. > >> Thanks, >> Kugan >> >> >> gcc/testsuite/ChangeLog: >> >> 2016-10-07 Kugan Vivekanandarajah >> >> * gcc.dg/tree-ssa/evrp6.c: New test. >> >> gcc/ChangeLog: >> >> 2016-10-07 Kugan Vivekanandarajah >> >> * tree-vrp.c (intersect_ranges): If we failed to handle >> the intersection and the other range involves computation with >> symbolic values, choose integer range if available. >> >> >> >From 54e92b7ddc47f6986e4dc79402d6808bb9c30c69 Mon Sep 17 00:00:00 2001 From: Kugan Vivekanandarajah Date: Sat, 8 Oct 2016 15:09:09 +1100 Subject: [PATCH 4/7] Revese value range before calling interset_range --- gcc/testsuite/gcc.dg/tree-ssa/evrp6.c | 22 ++++++++++++++++++++++ gcc/tree-vrp.c | 16 +++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/evrp6.c diff --git a/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c b/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c new file mode 100644 index 0000000..35d4d74 --- /dev/null +++ b/gcc/testsuite/gcc.dg/tree-ssa/evrp6.c @@ -0,0 +1,22 @@ + +/* { dg-do compile } */ +/* { dg-options "-O2 -fdump-tree-evrp" } */ + +extern void abort (void); + +int +foo (int k, int j) +{ + if (j >= 10) + { + if (j < k) + { + k++; + if (k < 10) + abort (); + } + } + + return j; +} +/* { dg-final { scan-tree-dump "\\\[12, \\+INF" "evrp" } } */ diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index 160adb5..c18c86f 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -10664,7 +10664,21 @@ evrp_dom_walker::try_add_new_range (tree op, tree_code code, tree limit) extract_range_for_var_from_comparison_expr (op, code, op, limit, &vr); if (old_vr->type == VR_RANGE || old_vr->type == VR_ANTI_RANGE) - vrp_intersect_ranges (&vr, old_vr); + { + if (range_int_cst_p (old_vr) + && !range_int_cst_p (&vr)) + { + /* intersect_range will use the left value range to keeps the + ASSERT_EXPR range and record the other range via an equivalence. + In this case, we are tracking value_ranges for same SSA_NAME in + different scope, so reverse it for better result. */ + value_range other_vr = vr; + vr = *old_vr; + vrp_intersect_ranges (&vr, &other_vr); + } + else + vrp_intersect_ranges (&vr, old_vr); + } /* If we found any usable VR, set the VR to ssa_name and create a PUSH old value in the stack with the old VR. */ if (vr.type == VR_RANGE || vr.type == VR_ANTI_RANGE) -- 2.7.4