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 ACEB6395B45B for ; Tue, 31 May 2022 16:40:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACEB6395B45B Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-218-v7v0ZOlTOj-ohPBuBs-CxQ-1; Tue, 31 May 2022 12:40:46 -0400 X-MC-Unique: v7v0ZOlTOj-ohPBuBs-CxQ-1 Received: by mail-qv1-f72.google.com with SMTP id x18-20020a0ce0d2000000b0046458e0e18bso2866499qvk.1 for ; Tue, 31 May 2022 09:40:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=EV3w79CUexPgv+8esnq46m9GxSs2RMG0TqQwSXTbzK8=; b=NaUBW+nGejMO9yYT/ikw5tAKfMvcOArfLL2p7ubqxV2cdabN8OuctygAs/8fGGxK3u mPG+PBabQihD0kMIWcy5r3TkDGaElrzT/Yqxh7su9cwa4d0Bj6GDDEq4dGq7OmvrmK3Q GAXW1zAa0z2jIOFFDIIz8k1P4VY1/PFY8AmQq5RBKDrG+UsSh+gQtC4iffeEmbzkvzpS 3PwFm9QhZo1VVR6jfIZyITJJyZ2b4tkJ2yc0/ecaBX4RY2Bq5wvYHBYpjyQ+wNyQbxq1 VaNdKJ7cUX3ScxWNs9KVBa8NQ3yGFsjoWL3hcgFMvqqksTHurBaUFWfumgQY0G7IJRw0 R1eA== X-Gm-Message-State: AOAM531qv9UmOJea4ambhN+JVBLm3O3iNtQrhAa5hWu0jR0FQ0yJQ9tp V/PTvG5tJ8xa8Sy9ZdaJzOLGw5P4EBJFYLopR86XpKc3EWJNtZXFt95XrhocwpyNntzkYmDKN+5 ZYO5I3D/Ag+elsjn9Yw== X-Received: by 2002:a05:620a:45a4:b0:6a4:bb4f:a8ff with SMTP id bp36-20020a05620a45a400b006a4bb4fa8ffmr27725295qkb.590.1654015245877; Tue, 31 May 2022 09:40:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxvW0Pi19SMV3Eh8dNAkvctioiE+AbRHBvKKSiprly6mkOgjzFqh3EujYZDeLN1Rcbb5JT2Iw== X-Received: by 2002:a05:620a:45a4:b0:6a4:bb4f:a8ff with SMTP id bp36-20020a05620a45a400b006a4bb4fa8ffmr27725277qkb.590.1654015245619; Tue, 31 May 2022 09:40:45 -0700 (PDT) Received: from [192.168.0.102] ([192.24.49.208]) by smtp.gmail.com with ESMTPSA id 23-20020a05620a06d700b0069fc13ce23dsm9273113qky.110.2022.05.31.09.40.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 31 May 2022 09:40:44 -0700 (PDT) Message-ID: <4e28ebc0-302e-20d8-9d9f-b76b2657e8b8@redhat.com> Date: Tue, 31 May 2022 12:40:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 2/5] Implement generic range temporaries. To: Aldy Hernandez Cc: GCC patches References: <20220530132751.1752112-1-aldyh@redhat.com> <20220530132751.1752112-2-aldyh@redhat.com> From: Andrew MacLeod In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-CA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 16:40:48 -0000 On 5/31/22 02:21, Aldy Hernandez wrote: > 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 > Im thinking about making the switch mid juneish...   i still have a few verifications to make.  We want to leave legacy for at least a while so we can manually switch back to it for investigation of any issues that come up during the transition.   so id expect early august time frame before trying to remove legacy....    at least legacy VRP. thats my thoughts anyway. Andrew Andrew