From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id AFAFF3836648 for ; Tue, 31 May 2022 06:22:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AFAFF3836648 Received: from mail-oi1-f198.google.com (mail-oi1-f198.google.com [209.85.167.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-434-0YZ1bdzsN2yT4_6IrVDGEQ-1; Tue, 31 May 2022 02:22:04 -0400 X-MC-Unique: 0YZ1bdzsN2yT4_6IrVDGEQ-1 Received: by mail-oi1-f198.google.com with SMTP id e206-20020aca37d7000000b0032da9a1ef61so586633oia.21 for ; Mon, 30 May 2022 23:22:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yadUvqKd+vy2QlI9OMdesX+9UkLUM+8iLnk94yY0CT0=; b=qELcOec7Lxql/L6MwIT9BTaaDTfZbPzZoq/ODNZuQpbNKCEMUMMinNKfVI+1z0U6Pb gX3K90WweJxo+/5cfaEJfJnUYqjd7gN3tsztOoY/z8R0YrOvtDKoc5XMIuxTdv2WQmA5 lru2PTJUDjDzcs6djpINLjGFpG0NwFOnh/yLVKLz67hei9BLXm1mgxZdCmC0edUSNyIn N980hj1cfgJUKz0Zc+6ooQ87i+oQrBdg12dQ05xJKIX/TYIT/35BwTr5lt6PHRI+L78b oEsEU5TmSqMhuotfxSBflPdZ7KCP3sjDGz5AVWvi7i7ctGZzt5qN77n4bkYqXxcsYKEC vo1w== X-Gm-Message-State: AOAM533bgpZA9pkEJGD5G/ZcFFYoiCaf7wuN00puBoM+tVPn5ikAFROh WtjOd3gS5otr1yFOxHwTT5E1cLeuGbj8CzvEInWnXgKgUj/xOzw21zx1WcUrSmu5ePfDE5nYTsr 7hrhNdVM0NvzluJa7fGHVKVPNYRw1mWeRDg== X-Received: by 2002:a05:6870:4307:b0:f2:3989:e85f with SMTP id w7-20020a056870430700b000f23989e85fmr12420081oah.265.1653978123381; Mon, 30 May 2022 23:22:03 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQ/NB50VwviWEA0ADAE/AXQQUvMo7BjqShpAY27ApzDmNV/AH+JRHiQlq0qgqSJj0uONtH6l79LYfDBKR4/A0= X-Received: by 2002:a05:6870:4307:b0:f2:3989:e85f with SMTP id w7-20020a056870430700b000f23989e85fmr12420072oah.265.1653978123135; Mon, 30 May 2022 23:22:03 -0700 (PDT) MIME-Version: 1.0 References: <20220530132751.1752112-1-aldyh@redhat.com> <20220530132751.1752112-2-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Tue, 31 May 2022 08:21:52 +0200 Message-ID: Subject: Re: [PATCH 2/5] Implement generic range temporaries. To: Andrew MacLeod Cc: GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2022 06:22:07 -0000 On Mon, May 30, 2022 at 4:56 PM Andrew MacLeod wrote: > > On 5/30/22 09:27, Aldy Hernandez wrote: > > Now that we have generic ranges, we need a way to define generic local > > temporaries on the stack for intermediate calculations in the ranger > > and elsewhere. We need temporaries analogous to int_range_max, but > > for any of the supported types (currently just integers, but soon > > integers, pointers, and floats). > > > > The tmp_range object is such a temporary. It is designed to be > > transparently used as a vrange. It shares vrange's abstract API, and > > implicitly casts itself to a vrange when passed around. > > > > The ultimate name will be value_range, but we need to remove legacy > > first for that to happen. Until then, tmp_range will do. > > > I was going to suggest maybe renaming value_range to legacy_range or > something, and then start using value_range for ranges of any time. > Then it occurred to me that numerous places which use value_range > will/can continue to use value_range going forward.. ie > > value_range vr; > if (!rvals->range_of_expr (vr, name, stmt)) > return -1; > > would be unaffected, to it would be pointless turmoil to rename that and > then rename it back to value_range. > > I also notice there are already a few instance of local variable named > tmp_range, which make name renames annoying. Perhaps we should use > Value_Range or something like that in the interim for the multi-type > ranges? Then the rename is trivial down the road, formatting will be > unaffected, and then we're kinda sorta using the end_goal name? OMG that is so ugly! Although I guess it would be temporary. Speaking of which, how far away are we from enabling ranger in VRP1? Because once we do that, we can start nuking legacy and cleaning all this up. Aldy