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
