From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35413 invoked by alias); 31 May 2019 15:36:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 35404 invoked by uid 89); 31 May 2019 15:36:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=minus_expr, NEGATE_EXPR, MINUS_EXPR, negate_expr X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 May 2019 15:36:36 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 586ADC066462; Fri, 31 May 2019 15:36:35 +0000 (UTC) Received: from [10.10.124.16] (ovpn-124-16.rdu2.redhat.com [10.10.124.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id 496F160BF7; Fri, 31 May 2019 15:36:34 +0000 (UTC) Subject: Re: On-Demand range technology [3/5] - The Prototype To: Richard Biener , Jeff Law Cc: GCC , Aldy Hernandez References: From: Andrew MacLeod Message-ID: Date: Fri, 31 May 2019 15:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00279.txt.bz2 On 5/29/19 9:11 AM, Richard Biener wrote: > On Tue, May 28, 2019 at 4:41 PM Jeff Law wrote: >> >>>> This aspect of symbolics would be handled by a relational/equivalence >>>> processing engine that would be follow on work. Using the same basic >>>> model as ranges, each tree code is taught to understand the relation >>>> between its operands, and then we can answer equivalency and relational >>>> accurately as well. It would be available for any pass to use >>>> independent of ranges. I will expound upon that a bit in the future >>>> directions section. >>> While I agree that symbolic ranges are a complication and that most >>> cases it currently handles are not "value-range" things I do not agree >>> with the idea that we can simply remove handling them and deal >>> with the fallout in some later point in the future. Eric may also be >>> able to show you "real" symbolic value-range magic. >>> >>> Note that symbolic ranges are already restricted to PLUS_EXPR >>> and MINUS_EXPR (and NEGATE_EXPR I think). There are >>> also "symbolic" (non-integer constant) ranges like [&a, &a]. >>> I've never seen [&a, &MEM[&a + 4]] but we wouldn't reject those >>> I think. >>> >>> You may have noticed that EVRP does not use symbolic ranges. > Btw, I probably misremembered this part - it is equivalences that > EVRP doesn't use. equivalences are the "other half" of relations > besides symbolic ranges. > I do get confused by this assertion...   From the EVRP dumps : Intersecting   int [b_6(D), b_6(D)]  EQUIVALENCES: { a_5(D) b_6(D) } (2 elements) and   VARYING to   int [b_6(D), b_6(D)]  EQUIVALENCES: { a_5(D) b_6(D) } (2 elements) Intersecting   int [a_5(D), a_5(D)]  EQUIVALENCES: { a_5(D) b_6(D) } (2 elements) and   VARYING and pushing new range for c_7(D): int [b_6(D), b_6(D)]  EQUIVALENCES: { b_6(D) c_7(D) } (2 elements) Visiting stmt if (a_5(D) == c_7(D)) it certainly does seem to have symbolics in the range..   ( [b_6, b_6]  ) and it does use equivalencies... presumably thats why its in the range, to help track them..  regardless, thats is how it gets cases we dont right now like   if (a == b && b == c)      if (a == c) It may not have symbolic expressions like [0, b_6 + 1] as end points like VRP does, or maybe it doesn't resolve them to anything other than varying, but it does appear to have symbolics?  Perhaps it resolves them immediately, but it does appear to use some partial bits of the symbolic machinery. We'd like to make this consistent everywhere and track the equivalencies outside of the range via a separate mechanism. >>> As already said I'd like to see VRP go but obstackles are >>> symbolic ranges and jump-threading (with Jeff promising >>> to handle the jump-threading part in the past). >> Right. FWIW, one of the follow-on items to this work is Aldy's >> improvements to backwards jump threading which utilizes the ranger >> framework -- the primary purpose of that work is to eliminate the need >> for jump threading in VRP. > But without relations it won't catch most of the cases... > > Richard. its catching what it quite a few new things....  and the relations/equivalencies are coming...  I haven't heard of any issues regarding equivalencies, but Aldy's  the one that been working with it, so he can speak to it better. Andrew