From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83361 invoked by alias); 24 Jul 2019 18:19: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 83265 invoked by uid 89); 24 Jul 2019 18:19:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1687 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; Wed, 24 Jul 2019 18:19:01 +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 54EF53086202; Wed, 24 Jul 2019 18:19:00 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-8.rdu2.redhat.com [10.10.112.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8C6E95C22D; Wed, 24 Jul 2019 18:18:58 +0000 (UTC) Subject: Re: [range-ops] patch 01/04: types for VR_UNDEFINED and VR_VARYING To: Richard Biener Cc: Andrew MacLeod , 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> From: Jeff Law Openpgp: preference=signencrypt Message-ID: <828e67b6-d52c-f50d-27bb-46b3734a0493@redhat.com> Date: Wed, 24 Jul 2019 18:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-07/txt/msg01600.txt.bz2 On 7/24/19 11:00 AM, Richard Biener wrote: [ Big snip, ignore missing reply attributions... ] >> it. But I'd claim that if callers are required not to change these >> ranges, then the callers are fundamentally broken. I'm not sure >> what the "sanitization" is really buying you here. Can you point >> to something specific? >> >>> >>> But you lose the sanitizing that nobody can change it and the >>> changed info leaks to other SSA vars. >>> >>> As said, fix all callers to deal with NULL. >>> >>> But I argue the current code is exactly optimal and safe. >> ANd I'd argue that it's just plain broken and that the >> sanitization you're referring to points to something broken >> elsewhere, higher up in the callers. > > Another option is to make get_value_range return by value and the > only way to change the lattice to call an appropriate set function. I > think we already do the latter in all cases (but we use > get_value_range in the setter) and returning by reference is just > eliding the copy. OK, so what I think you're getting at (and please correct me if I'm wrong) is that once the lattice values are set, you don't want something changing the recorded ranges underneath? ISTM the way to enforce that is to embed the concept in the class and enforce it by not allowing direct manipulation of range by the clients. So a client that wants this behavior somehow tells the class that ranges are "set in stone" and from that point the setters don't allow changing the underlying ranges. I just want to make sure we're on the same page WRT why you think the constant varying range object is useful. jeff