From patchwork Thu Jan 26 09:04:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 719995 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3v8GG74FD2z9t1T for ; Thu, 26 Jan 2017 20:04:56 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="krcSLsM3"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=OeXnVFGKsG3FeGy 8BIfkUOv0B4BPuGFWXLbxCCFrdgqUDv6dLN08xBllUNA+g4vognDmFxM/culTSk+ rIlbvrfNhc3gmqbdRfvy3HbliJz2hAP6UwoX7M99zXwiK3rFefOfeaFy82paUtmf a5nUVUsxLsf466PCa/Ry0zUByPiM= 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 :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=CT5PM9AEEd5d5wVaYwj0r UhD8As=; b=krcSLsM3Ntm92TwgO8/8HNzxTG9ZVFNj6YCPox7w2GuAkgudtiaXm TW2QLYh9PPDI4wWiXiaqP0p51lIP5rs4ifpvq3pbsX51QhONg1oELCIetaWiztM2 qGYr2dqhPgFRkf93Ix79zgVbS3b1WQAMYaCYIl/x5R4DFSYJ2ICohs= Received: (qmail 37434 invoked by alias); 26 Jan 2017 09:04:45 -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 37410 invoked by uid 89); 26 Jan 2017 09:04:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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=BinChengarmcom, sk:BinChe, U*Bin.Cheng, sk:Bin.Che X-HELO: mail-ot0-f194.google.com Received: from mail-ot0-f194.google.com (HELO mail-ot0-f194.google.com) (74.125.82.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 26 Jan 2017 09:04:34 +0000 Received: by mail-ot0-f194.google.com with SMTP id 65so26680747otq.2 for ; Thu, 26 Jan 2017 01:04:33 -0800 (PST) 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=AjSZyziNPa5PIUH5uzAbgjFt3ykjDqzp50+5+liOHPE=; b=ACpr3Xulwb50B3SDsRKMqshKYaSJzFihNyM+IB1SgnFBlgPowVT/vbdNcABvdbGxJE W37jMvz5iKF9Iop2sqUuH4ORZSPU35wBM6ZiTjUKNRlRP8C9GzZB136W+lVJLPohW4aE UuLiEMu9YV5fcIcomYnaWRoiNMWrSe9OFmkwhezalFKuEOR6YmwbPyPYwblwcL0k7YO6 HTsuCR+tl/LGYmoVHybAyeZ80bIhAtpX8Bw7inKIa/uHLBRi+1DL/ixtJbsfrxX0t1er Ddq+HnCYS84uaJ1Lrz9zydb67INh/NzAdJ6z0P8ZqHDZf9TJ5l6nlYLoil1AMFU2nKGh HwOA== X-Gm-Message-State: AIkVDXLqIpZ68R6zVCE/01HPs68ILWTE29jkTzRRarJaecXh+Wve0LhSJmiVBBvYhKH3HiZLhQywNICrkY0/KA== X-Received: by 10.157.11.37 with SMTP id a34mr872725ota.258.1485421472230; Thu, 26 Jan 2017 01:04:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.42.12 with HTTP; Thu, 26 Jan 2017 01:04:31 -0800 (PST) In-Reply-To: References: From: Richard Biener Date: Thu, 26 Jan 2017 10:04:31 +0100 Message-ID: Subject: Re: [PATCH PR71437]Prefer symbolic range bound if the var doesn't have useful range. To: Bin Cheng Cc: "gcc-patches@gcc.gnu.org" , nd X-IsSubscribed: yes On Wed, Jan 25, 2017 at 5:30 PM, Bin Cheng wrote: > Hi, > As analyzed in PR71437, it's a missed PRE issue due to missed jump threading, > and then due to inaccurate VRP information. In function extract_range_for_var_from_comparison_expr, > we compute range for variable "a" under condition that comparison like "a <= limit" > is true. It extracts limit's range information and set range [MIN, limit_vr->max] to var. > This is inaccurate when limit_vr->max is MAX. In this case the final range computed > is [MIN, MAX] which is VARYING. In fact, symbolic range info [MIN, limit] is better here. > This patch fixes PR71437 by making such change. It also handles ">=" cases. > > Bootstrap and test on x86_64 and AArch64 finished. All tests are OK except test > gcc.dg/tree-ssa/pr31521.c. I further investigated it and believe it's another missed > optimization in VRP. Basically, operand_less_p is weak in handling symbolic value > range. Given below value ranges: > x: [1, INF+] > a: [-INF, x - 1] > b: [0, INF+] > It doesn't know that "x - 1 < INF+" must be true, thus (intersect a b) is [0, x - 1]. > I believe there may be other places in which symbolic value range is not handled > properly. So any comment? The patch looks heuristically good though, for a < limit we chose [MIN, limit - 1] rather than [MIN, +INF - 1] which would be a non-varying integer range (and we usually prefer those). So maybe restrict it to LE/GE_EXPR? That also fixes pr31521.c but unfortunately regresses your new testcase again... so much for heuristics ;) You are correct about limitations in operand_less_p and improvements there are of course welcome. Btw, I played with note the overflow_infinity case which would make us drop to varying below. Thanks, Richard. > Thanks, > bin > > 2017-01-24 Bin Cheng > > PR tree-optimization/71437 > * tree-vrp.c (extract_range_for_var_from_comparison_expr): Prefer > symbolic range form if limit has no useful range information. > > gcc/testsuite/ChangeLog > 2017-01-24 Bin Cheng > > PR tree-optimization/71437 > * gcc.dg/tree-ssa/pr71437.c: New test. Index: gcc/tree-vrp.c =================================================================== --- gcc/tree-vrp.c (revision 244920) +++ gcc/tree-vrp.c (working copy) @@ -1663,7 +1663,12 @@ extract_range_for_var_from_comparison_ex { min = TYPE_MIN_VALUE (type); - if (limit_vr == NULL || limit_vr->type == VR_ANTI_RANGE) + if (limit_vr == NULL || limit_vr->type == VR_ANTI_RANGE + || (limit_vr->type == VR_RANGE + && ((cond_code == LE_EXPR + && vrp_val_is_max (limit_vr->max) + && compare_values (limit_vr->min, limit_vr->max) != 0) + || is_overflow_infinity (limit_vr->max)))) max = limit; else { @@ -1703,7 +1708,12 @@ extract_range_for_var_from_comparison_ex { max = TYPE_MAX_VALUE (type); - if (limit_vr == NULL || limit_vr->type == VR_ANTI_RANGE) + if (limit_vr == NULL || limit_vr->type == VR_ANTI_RANGE + || (limit_vr->type == VR_RANGE + && ((cond_code == GE_EXPR + && vrp_val_is_min (limit_vr->min) + && compare_values (limit_vr->min, limit_vr->max) != 0) + || is_overflow_infinity (limit_vr->min)))) min = limit; else {