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 DE3E038560A5 for ; Mon, 30 May 2022 14:56:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DE3E038560A5 Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-78-n1-Oo9-uMraqle5skm2BCA-1; Mon, 30 May 2022 10:56:09 -0400 X-MC-Unique: n1-Oo9-uMraqle5skm2BCA-1 Received: by mail-qk1-f197.google.com with SMTP id i2-20020a05620a144200b006a3a8651de1so8787409qkl.14 for ; Mon, 30 May 2022 07:56:09 -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:references:from:in-reply-to :content-transfer-encoding; bh=rmIEGellmMfjJw7YMUU5mMqY/e9ERSjL64HAHwpNHRc=; b=1fOwMihMQqrYKfkmkWZdRv4avaYej6YaChvo0VkxbLiz/PJjFt+oJ5TLBpWnb/Risl 53ikozrKV8/qmbFcjCRR2yi03mo0BruiSEB0HbXlyKb75HxoPzA9/3DMGmwN+JfG8xgf ed2HbKvUdkrWaTAxCvk89nGPON7x0SKKzZB1dlkinCrr+PHVLpr/tKQXZhkt4POAMP5w uU/XIRNwZunvdLAATp0+OfVvX6Q92vmhSCENHDJvQUPqsEXrLJTeTicnR/U0ggrIGu+F GKwHfVFbrKZny4jj0qLEhKw9prQFXGkT4uaGhd6t5zqOxcTtqBRz5lwoQrdOmmUFjySs cr+g== X-Gm-Message-State: AOAM5306YDnxwOEWK7rmJB/wylZxD3Tmzv2Da6x0NPLk/OJN/B/ilWg3 kUJFUsghTNSIZlTUNL9SxrHYCLxPF+PojEjsWc1OYN1AIJFFIKTpMIAxckeEx0NEUjzz0LOPqiU 2/o0zkpjScT0uNJHaIQ== X-Received: by 2002:a05:620a:4256:b0:67e:87a1:ffdd with SMTP id w22-20020a05620a425600b0067e87a1ffddmr36857438qko.647.1653922568846; Mon, 30 May 2022 07:56:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySsvMRX6+FDnd6jVGvBCg/KN2agzkC953Nw4SHiLy5Zb8WsW3H3t0hXXGal1Cm7UHnTcjwIg== X-Received: by 2002:a05:620a:4256:b0:67e:87a1:ffdd with SMTP id w22-20020a05620a425600b0067e87a1ffddmr36857429qko.647.1653922568603; Mon, 30 May 2022 07:56:08 -0700 (PDT) Received: from ?IPV6:2607:fea8:a261:5e00:6701:24de:7b30:568f? ([2607:fea8:a261:5e00:6701:24de:7b30:568f]) by smtp.gmail.com with ESMTPSA id f1-20020ac87f01000000b002f39b99f6bbsm7970797qtk.85.2022.05.30.07.56.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 May 2022 07:56:08 -0700 (PDT) Message-ID: Date: Mon, 30 May 2022 10:56:06 -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 , GCC patches References: <20220530132751.1752112-1-aldyh@redhat.com> <20220530132751.1752112-2-aldyh@redhat.com> From: Andrew MacLeod In-Reply-To: <20220530132751.1752112-2-aldyh@redhat.com> 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.1 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: Mon, 30 May 2022 14:56:12 -0000 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? Andrew