Project Ranger Update

[Andrew MacLeod]

With the end of stage 1 approaching, I figure its time for an update on 
project Ranger.

range-ops was integrated with trunk on Oct 2, all ranges are generated 
now using this component.

GORI-computes was the other piece we were hoping to get in. This 
component is "Generates Outgoing Range Info" for blocks, and basically 
replaces the assert mechanism.  We have reworked it and wired it into 
EVRP and can successfully use it to generate ranges for EVRP.   The 
unexpected problem we encountered was actually related to the 
limitations of value_range.

Aldy has successfully wired GORI in to EVRP.   We can generate the a 
range the current way, also generate a range with GORI, and then compare 
them.   While we found we could generate some ranges better, ie:

     improved: _2 from: unsigned int [1, +INF] to: unsigned int [8, +INF]

  there was often a lot of noise where we'd just generate something 
"different".  ie:

    _47 from: short unsigned int ~[11, 11] to: short unsigned int ~[8, 9]

This happens because we knew is wasn't 8,9 or 11... but the limitation 
of a single subrange/anti-range in value_range means we couldn't 
represent it.   We found this to be a very frequent occurrence, and my 
worry is that if we generate  a bunch of different ranges, we end up 
with bug reports where we don't optimize/warn about something we use to. 
Fixing something due to a representational problem like this is not 
easily resolved without hackery, and I'm not interested in chasing down 
a bunch of problems that are only problems due to the limitations of 
value_range.

So, we've decided on a change of plan, and will *not* try to get GORI in 
before the end of stage 1.

Instead, we're going to move to branch development.  the branch is 
"ranger", which was our staging branch and has the initial attempt at 
bringing GORI to trunk.  This will become our ongoing development 
branch, and once we get up to speed we will post to gcc-patches the 
current differences and all future patches with the [ranger]  tag. This 
will allow anyone that is interested to follow and/or comment.   I would 
expect this to happen shortly after stage 1 ends, if not before.  We 
will also try to keep this branch merged with trunk on a regular basis

we'll start with GORI being wired into EVRP and producing ranges which 
are the intersection of EVRPs current range, and what GORI produces.  
The short term goal is that GORI will always produce ranges where this 
intersection is the same as what GORI produces, thereby eliminating the 
need for the ASSERT mechanism.

The path from here to there involves doing the following work on the branch:
  * enhance value_range to support multiple sub-ranges.... effectively 
merging irange and value_range. We think we can add multiple sub-ranges 
while maintain the current behaviour for ANTI-ranges and symbolics when 
there is only a single subrange. We can then more precisely evaluate 
whether the new ranges are better or not.
  * the long awaited equivalence/relational tracker so we can remove 
symbolics and anti-range from value_range
  * re-integration of the on-demand framework with GORI.

Currently we are fleshing out a few changes into trunk before stage 1 
ends to facilitate branch maintenance leading through to the next stage 1.

As we come up to speed and start working with each major piece, we'll 
provide a rundown of whats involved.

Thats it for now... next update in a couple of weeks!

Andrew