From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10304 invoked by alias); 1 Aug 2019 16:35:00 -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 10290 invoked by uid 89); 1 Aug 2019 16:34:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=desire, computational, examined 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; Thu, 01 Aug 2019 16:34:58 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F3801C0B2EDA; Thu, 1 Aug 2019 16:34:56 +0000 (UTC) Received: from [10.10.121.61] (ovpn-121-61.rdu2.redhat.com [10.10.121.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id 34DCF600C6; Thu, 1 Aug 2019 16:34:54 +0000 (UTC) Subject: Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING To: Richard Biener Cc: Jeff Law , Aldy Hernandez , gcc-patches References: <481033aa-6ecc-3bcb-c874-becee14c5605@redhat.com> <27d3db25-ea95-33f4-57fb-e9a4a40d7341@redhat.com> <1a0a328e-74bb-15cb-40fb-09944fe2b84c@redhat.com> <3ebd8a38-9478-7899-5067-b4cb220d2edf@redhat.com> <828e67b6-d52c-f50d-27bb-46b3734a0493@redhat.com> <78846d0a-354e-b73a-6e15-123752038fb2@redhat.com> From: Andrew MacLeod Message-ID: <0afb589c-d0e8-4775-5d79-e5e9e57c42dd@redhat.com> Date: Thu, 01 Aug 2019 16:35: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-08/txt/msg00056.txt.bz2 On 8/1/19 10:11 AM, Richard Biener wrote: > On Thu, Aug 1, 2019 at 1:24 AM Andrew MacLeod wrote: > >> Aldy started this relatively straightforward submission a month ago (!! >> July 1st!), and we've made virtually no progress since then. > Actually I think it's a waste of time on my side since I actually sat > down and looked at the branch - because while you posted several > "merge plans / proposals" the actual patches you proposed for integration > were just changes to the existing code. But then when I tried to They are preliminary patches which enable us to align irange and value_range so they can be used interchangeably as the range class everywhere. We've adjusted irange on the branch to align with value_range, and these tweaks to the value_range API make them fully interchangeable. So yes, this first set of patches are just changes to the existing code... We need them before we can bring in range-ops.    After that comes the outgoing range computational component, but I'm worried we're short on time for that now :-(  we'll see. > understand why you need those by looking at the branch (OK, criticizing > some stuff I saw there) you said "well, don't look - it's all just a prototype > and even the APIs are not finished". I explained numerous times why we needed the changes, you appear to simply not believe me. There should not have been a need to look at unprepared code. As for being not finished, the API is being tweaked for trunk.. 2 things in particular:  1)  I'm adding a type to the calls since we won't have a type for undefined any more. The aggregation of sub-ranges always started with undefined and built up from there, and it can no longer find the type from undefined.  2)  The Implementation of each operation was still using chains of calls into legacy code which often used big switches...  I'm collapsing those into a basic operation call on wide-ints  which is being added to the API.    This will dramatically change the look of the file, without changing its basic behaviour. So its virtually the same code, but with a very different (and cleaner) look designed for trunk...  we didn't really care what it looked like on the branch, we just wanted functionality...  and it shows.  Hence my desire to not have it critiqued :-)  The intention was always to rework it for trunk before having it examined. I'll also modify the entire file to use value_range instead of irange.  We don't want to contaminate trunk with pointless #defines or other silliness. We'll manage irange compatibility for range-ops on the branch. The varying min/max change we were trying to get in is a hard prerequisite for value_range to function properly in this role. > That makes me wonder why you do changes to trunk or proposing > merge plans when you've not even finished designing stuff... > > As said, I feel I am wasting my time here so please feel free to > do whatever you are up to with VRP. > > I did help with considerable resources even during last stage1/3 with > "fixing" the half-way conversion of value_range to a class. I've not > manged to beat sense into the wide-int-range.h API, but oh well. yes, and I really do appreciate that work, it was critical to paving the way to allowing us to use value_range instead of irange...  We just need these final couple of things to finish that transition, and they were just not happening, thus my reaction. I think the new  range-op operation on wide-ints that is being added to the API will probably replace most, if not all, of the wide-int-range.h stuff...  We'll see how it goes when I finally get back to finishing it. Anyway, I'm off after today for a week, so we wont do anything further until I get back. The weekend will be here shortly... Have a good one. Andrew