Project Ranger Status

Andrew MacLeod
Fri Jul 24 13:54:03 GMT 2020

We originally intended to start pushing ranger code into trunk shortly 
after the start of stage 1, but of course.. delays, delays :-)

So here is the latest status/changes since last fall and our proposed 
time-line going forward.  I'll do the executive summary here, and more 
details at each submission stage.

1) multi-range support - Imminent

We have moved the representation of our multi-range class  from wide-int 
to trees, and merged it with the value_range class .  There is now a 
base class which "recognizes" a 1 sub-range case as a special legacy 
mode which supports ANTI_RANGE and incorporates the original value_range 
code.  Multi-range is fully interoperable/compatible with value_range 
code now and all existing code which uses value_range still operates 
exactly the same as it did.. its just slightly different under the covers.

range-ops has been returned to working in multi-range mode again now 
that its compatible with value_range. Any consumer working with ranges 
can switch to multi-range by switching to the multi-range API.

This code is currently going through a complete fedora build, and 
assuming that passes, Aldy will be submitting it for trunk along with 
various details and performance results in the coming week or so.

2)  Ranger - Mid August

The on-demand ranger has been substantially simplified, with well 
defined components contained in just a few source files.    It is queued 
up for trunk submission after the multi-range code goes in..

Initially, we plan to enable it for a few client passes which we will 
describe at submission time (mostly the same passes as last years 
presentation discussed) , along with a VRP pass which will run 
immediately before EVRP called RVRP.  It uses the same dom-walking 
infrastructure that EVRP uses, but it still has a lack of relational 
processing (to be addressed next)

At submission time I'll provide the details, as well as performance and 
shortcomings once it has also passed thru a fedora build cycle. This 
will also include the test suite adjustment strategy.

3) Equivalency/Relational Processing - Mid September(?)

  Finally, the relation code will come, probably in mid September. The 
proof of concept oracle prototype looked good, so I'm re-working parts 
of it for performance in production code.

Once the relation code is in place, we will work on whatever remaining 
differences there are between EVRP and the new RVRP pass.
   - with RVRP running immediately before EVRP, we can identify anything 
EVRP finds of significance that is missed.
   - We can also run RVRP immediately after EVRP  and identify things 
RVRP gets which EVRP does not.


We know we get immediate benefit from multiple passes when they are 
switched to ranger, and we'd like to get that enabled ASAP  allowing the 
code to be rigorously exercised during the rest of stage 1.

The RVRP pass will be a work in progress, and it is 100% self contained 
in one file, simply operating as a ranger client just like the other 
passes.   If we reach the end of stage 1, and for whatever unforeseen 
reason RVRP is not performing satisfactorily enough to replace EVRP, we 
simply turn it off.  If it is operating well enough, then we turn of 
EVRP.  We can decide towards the end fo the stage.

Thats a quick synopsis of the current ranger work. Over the next 2 
months we hope to get all of the components into trunk and available for 
general use.

Andrew & Aldy

More information about the Gcc mailing list