From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105018 invoked by alias); 24 May 2019 15:50:19 -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 104934 invoked by uid 89); 24 May 2019 15:50:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-4.1 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=obstacle, guys, it.=c2, symbolics?= 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, 24 May 2019 15:50:15 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 211CDC05B022; Fri, 24 May 2019 15:50:13 +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 D02665C1B4; Fri, 24 May 2019 15:50:11 +0000 (UTC) Subject: Re: On-Demand range technology [3/5] - The Prototype To: Richard Biener Cc: GCC , Jeff Law , Aldy Hernandez References: From: Andrew MacLeod Message-ID: Date: Fri, 24 May 2019 15:50: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/msg00210.txt.bz2 On 5/23/19 9:10 AM, Richard Biener wrote: > On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod 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. sure, I'd love to see a case we can't get that having symbolics in the range helps with.  (note I see you guys have replied with an example.  I'll reply there, but will note it is actually a relation issue, so my assertion stands) And we aren't talking about utting this code in and someday getting around to it.   Equivalencies/relations are the very next thing to tackle,  and I expected at least a proof of concept as a requirement.  I just don't want to proceed with any follow up work until a direction is set for the core aspects. > 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. Other than for equivalences?  it appears to still track them via ranges to eliminate things like : if (a == b && b == c)      if (a == c) Intersecting   int [c_7(D), c_7(D)]  EQUIVALENCES: { b_6(D) c_7(D) } (2 elements) and   VARYING to   int [c_7(D), c_7(D)]  EQUIVALENCES: { b_6(D) c_7(D) } (2 elements) I noticed this is how it continues to handle relational problems, so they are there. > > 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). > I also consider symbolics an obstacle, only in a different way :-) Andrew