From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74901 invoked by alias); 28 Nov 2017 11:49:02 -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 74890 invoked by uid 89); 28 Nov 2017 11:49:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_NUMSUBJECT,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-spam-relays-external:74.125.82.67, H*RU:74.125.82.67 X-HELO: mail-wm0-f67.google.com Received: from mail-wm0-f67.google.com (HELO mail-wm0-f67.google.com) (74.125.82.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Nov 2017 11:48:59 +0000 Received: by mail-wm0-f67.google.com with SMTP id x63so1258220wmf.4 for ; Tue, 28 Nov 2017 03:48:59 -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=eCLodb+3F8bl/Q6FVOe92lkiYwkc+RDOB8bAH53ZTc4=; b=E3VYg2qc5gcILBZPW3wBIF2XCuq9FbG+tC5lgr9L9zyqb+zyFDgLiZH+nUM/MFedjP bN0x5VSggayQrCnTYpGw5khMOvc0J/xoND6145ebdFXKf7IW3xY4nQzU5JhaV8KAzOVj PzcjrSSjyUtmnMvuo+do71tzaHFj2l6Gs2GmtIrv4kBjRQ+sAiZmvrEzi97sdygEsT5E 6yt9jUbPxJJ6RWXT2Ob1tJdP5vac9MdnNKcB8jguXg0m3KVdSK5T3zncbAbEFfGAVnP4 D4CCheWEQ26Q93eEnrPu01XhjDGxoGWdmvBVhBXVehCjrKjI3LAan72Y9KitFYOWVEl2 S/ww== X-Gm-Message-State: AJaThX4nYLRagrG7GOBUOP6l2PBpdP5+ealwpLICcxiVaCO7SZxy9TFg jUOXUxkQg4EFtxDRF+RSgN+NPx64pzYLYyvrQZ8hkQ== X-Google-Smtp-Source: AGs4zMZyih8N+MvCY6QPuh+9F9MpOynIquY92TwzSmqnwHGCB0zEPBJaxseTShzFwaAaE5UY9lWCw/KVjJG2gDEZ8fU= X-Received: by 10.80.144.168 with SMTP id c37mr2322595eda.182.1511869737682; Tue, 28 Nov 2017 03:48:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.143.34 with HTTP; Tue, 28 Nov 2017 03:48:57 -0800 (PST) In-Reply-To: <6d9e93c4-25ae-10ce-5e8c-3e28d61b9777@redhat.com> References: <80038401-a229-aba2-712d-1082aaa39b65@redhat.com> <6d9e93c4-25ae-10ce-5e8c-3e28d61b9777@redhat.com> From: Richard Biener Date: Tue, 28 Nov 2017 11:55:00 -0000 Message-ID: Subject: Re: [RFA][PATCH] Use SCEV conditionally within vr-values and evrp range analysis - V2 To: Jeff Law Cc: gcc-patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02394.txt.bz2 On Mon, Nov 27, 2017 at 5:43 PM, Jeff Law wrote: > On 11/23/2017 05:49 AM, Richard Biener wrote: >> On Thu, Nov 23, 2017 at 1:16 AM, Jeff Law wrote: >>> >>> Clients of the evrp range analysis may not have initialized the SCEV >>> infrastructure, and in fact my not want to (DOM for example). >>> >>> Yet inside both vr-values.c and gimple-ssa-evrp-analyze.c we have calls >>> into SCEV (that will fault/abort if SCEV is not properly initialized). >>> >>> This patch allows clients of vr-values.c and gimple-ssa-evrp-analyze.c >>> to indicate if they want SCEV analysis. >>> >>> Bootstrapped and regression tested by itself as well as with the DOM >>> patches to use EVRP analysis (which test the "don't want SCEV path). >>> >>> OK for the trunk? >> >> There's also scev_initialized_p () which you could conveniently use. > Yea, that worked fine and is (of course) much simpler. > > Bootstrapped and regression tested in isolation as well as on top of my > ongoing work to remove jump threading from tree-vrp.c. > > OK for the trunk now? Ok. Richard. > Jeff > > > * gimple-ssa-evrp-analyze.c > (evrp_range_analyzer::record_ranges_from_phis): Only use SCEV to > refine ranges if scev_initialized_p returns true. > * vr-values.c (vr_values::extract_range_from_phi_node): Likewise. > > diff --git a/gcc/gimple-ssa-evrp-analyze.c b/gcc/gimple-ssa-evrp-analyze.c > index 68a2cdc..38fb0db 100644 > --- a/gcc/gimple-ssa-evrp-analyze.c > +++ b/gcc/gimple-ssa-evrp-analyze.c > @@ -176,7 +176,8 @@ evrp_range_analyzer::record_ranges_from_phis (basic_block bb) > to use VARYING for them. But we can still resort to > SCEV for loop header PHIs. */ > struct loop *l; > - if (interesting > + if (scev_initialized_p () > + && interesting > && (l = loop_containing_stmt (phi)) > && l->header == gimple_bb (phi)) > vr_values.adjust_range_with_scev (&vr_result, l, phi, lhs); > diff --git a/gcc/vr-values.c b/gcc/vr-values.c > index 2d11861..e617556 100644 > --- a/gcc/vr-values.c > +++ b/gcc/vr-values.c > @@ -2935,7 +2935,8 @@ scev_check: > scev_check can be reached from two paths, one is a fall through from above > "varying" label, the other is direct goto from code block which tries to > avoid infinite simulation. */ > - if ((l = loop_containing_stmt (phi)) > + if (scev_initialized_p () > + && (l = loop_containing_stmt (phi)) > && l->header == gimple_bb (phi)) > adjust_range_with_scev (vr_result, l, phi, lhs); > >