From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116401 invoked by alias); 24 May 2019 15:51:53 -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 116391 invoked by uid 89); 24 May 2019 15:51:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=UD:tree-ssa-uninit.c, workers, primitive 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:51:52 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 08E7E6EB97; Fri, 24 May 2019 15:51:51 +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 BA9505F7C2; Fri, 24 May 2019 15:51:49 +0000 (UTC) Subject: Re: On-Demand range technology [5/5] - Looking to the future. To: Richard Biener Cc: GCC , Jeff Law , Aldy Hernandez References: <47283c00-4da8-31fa-232c-1a127ad95284@redhat.com> From: Andrew MacLeod Message-ID: <5ae4fb04-8d6e-7c18-75b0-740bfff741d8@redhat.com> Date: Fri, 24 May 2019 15:51: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/msg00212.txt.bz2 On 5/23/19 10:07 AM, Richard Biener wrote: > On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote: >> >> This aspect of all calculations being driven from the opcode and >> combined generically without special casing at a higher level is both >> very powerful and less prone to produce errors. Our initial experiences >> involved debugging a lot of ranges because they didn’t look right… but >> it would inevitably turn out that a sequence of statements and >> conditions ended up determining an unexpected range, we just couldn’t >> understand from looking at it how it was arrived at. > Sounds like those primitive workers for ranges, relations and bitmasks > should be factored out where they are not already as a prerequesite, > not as some future project? Note the bitmask ones are already > (just residing in tree-ssa-ccp.c), likewise the wide-int based range > ones are (mostly I think). Relations are missing unfortunately > and passes like tree-ssa-uninit.c would benefit from such machinery > (or rather contain another copy of such machinery). > > Of course factoring always comes with commoning because usually > in GCC you find at least two implementations of everything. > > Richard. > > Yes, this would indeed be the case, I also consider the relations functionality as required, or to at least demonstrate a viable path forward that is being worked on. The bitmask operations are currently only used in full VRP (?) but they probably aren't a lot of work, I'd put them at a lower priority until VRP is slated to go. I would really like to see a single implementation for each of these things centrally maintained and handled generically.   At this point I don't think it was  realistic to proceed any further until we get some sort of agreement on a path forward to base it on.  we have found trying to maintain a common base with VRP just for ranges to be a fair amount of work on the side, so adding other things on top of that seems nightmarish :-) So let me see if I can summarize everything to this point. 1 * The range-ops infrastructure to solve for other operands coupled with the windback calculations within a block is desirable to replace the assert mechanism. 2 * common rangeops-like primitives for relational and bitmask  also seems desirable. 3 * You are not convinced the on demand component can/should replace the EVRP dominator walk. Does that about sum it up? 1 - The way everything is structured, both range-ops and the gori-computational component are independent of the on-demand engine. There is reason to believe those can be integrated with E/VRP as we are sort of doing that under the covers now.      what function does register_edge_assert() perform?  is it producing ranges just for outgoing edges for a block? and then you apply whatever range you currently have to that and this gives you a range going into the block on the other end of the edge?   If so, that functionality maps pretty close to what gori-computes provides.  It has a single API which returns whatever range restrictions an edge puts on an ssa-name. there would have to be some tweaking to work with symbolics since we hate those and they aren't currently handled. 2 - implementing range-ops like routines for relations and eventually bitmasks should not be too difficult. The process is pretty straightforward.  I will need to work on the relation tracking/querying, but that was pretty much in plan as the next task anyway.   I had pushed bitmasks way down the list as "eventually" since I think that is only in full VRP and a lower priority until considering VRP for removal. 3 - Give me a few days to mull over some details on how some of this may all coexist and I'll get back to you next week. Andrew