On Mon, May 30, 2022 at 4:56 PM Andrew MacLeod <amacl...@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
