public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew MacLeod <amacleod@redhat.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: GCC patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH 2/5] Implement generic range temporaries.
Date: Tue, 31 May 2022 12:40:43 -0400	[thread overview]
Message-ID: <4e28ebc0-302e-20d8-9d9f-b76b2657e8b8@redhat.com> (raw)
In-Reply-To: <CAGm3qMX1FAJbcy1keFa6tkWY9uGoQYfzPh1OG-OLivMWcf-=+g@mail.gmail.com>

On 5/31/22 02:21, Aldy Hernandez wrote:
> On Mon, May 30, 2022 at 4:56 PM Andrew MacLeod <amacleod@redhat.com> 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


  reply	other threads:[~2022-05-31 16:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-30 13:27 [PATCH 1/5] Implement abstract vrange class Aldy Hernandez
2022-05-30 13:27 ` [PATCH 2/5] Implement generic range temporaries Aldy Hernandez
2022-05-30 14:56   ` Andrew MacLeod
2022-05-31  6:21     ` Aldy Hernandez
2022-05-31 16:40       ` Andrew MacLeod [this message]
2022-06-01  9:01       ` Aldy Hernandez
2022-05-30 13:27 ` [PATCH 3/5] Convert range-op.* to vrange Aldy Hernandez
2022-06-01  9:01   ` Aldy Hernandez
2022-05-30 13:27 ` [PATCH 4/5] Revamp irange_allocator to handle vranges Aldy Hernandez
2022-06-01  9:02   ` Aldy Hernandez
2022-05-30 13:27 ` [PATCH 5/5] Convert ranger and clients to vrange Aldy Hernandez
2022-06-01  9:04   ` Aldy Hernandez
2022-06-27  0:33     ` Xi Ruoyao
2022-06-01  8:57 ` [PATCH 1/5] Implement abstract vrange class Aldy Hernandez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e28ebc0-302e-20d8-9d9f-b76b2657e8b8@redhat.com \
    --to=amacleod@redhat.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).