On 4/28/21 2:24 AM, Richard Biener wrote:
The final thing I plan to incorporate is some documentation of ranger
technology. There are a lot of features and data available in the
Ranger ecosystem that could be useful elsewhere. No one really knows
about them, and rather than trying to write everything up at once, I
propose to write a *[ranger tech] *post once a week. I'd send it to this
gcc list introducing some Ranger component and how it works. Small
pieces like this make it more likely someone will read and identify
something useful to them. And perhaps we can find ways to make them more
generally applicable to other uses. These will then be incorporated into
a wiki-page for documentation purposes, and over time should form a good
basis of documentation without overwhelming anyone (including myself :-)
with a huge doc drop all at once.
Its been a busy 6 months, and it appears to also be a very busy stage 1.
Please, feel free to offer comments on this plan or on individual
components as we introduce them.
I'd really prefer to keep a simple lattice-style value range analysis pass
so we have sth we can run at -O1 over those large machine generated
codes where ranger blows up on. EVRP was supposed to be that - I know
you're somewhat obsessed to turn everything into "ranger" - and for
the core value-range primitives I agree that we only want "one", but then
there are advantages to lattice-style operation.
IF we cannot contain a large CFG, then sure. I also think we need
something with little to no overhead for -O1. I wouldn't want to replace
anything if we don't have a solution that is at least as good, and I
won't tear out anything without consensus.
During this cycle, there are a few enhancements which I hope will
address most of the issues.
1) most of the large CFG issues are due to the on entry cache
explicitly tracking ranges everywhere once they aren't varying.. over
large CFGs where nothing else is happening, this consumes both memory
and time for little to no gain, and I'm not happy with its current
functioning. I plan to replace this implementation with one that is
dominance based, and only has to store ranges in blocks which are
actually different than their predecessor. I anticipate this will make
a huge difference in those big CFG programs.
2) It wasn't mentioned (as I forgot at the time) , but I am looking
at various enhancements when processing things "in order" like we do
with EVRP. One such thing is to use the "current blocks" on-entry cache
as "current" value, and then make it "on-exit" when the block is done...
(which is approximately what EVRP is doing today.).. then we also don't
need to keep any block caches further back in the program.
3) There is also room to experiment with modes not resolving backedges
as well.. which if combined with 2) should prevent any mass explosions..
and gets us fairly close to the mechanism that EVRP uses today
4) finally, when the relation engine is in place and all the
range-ops/gori bits are simply using it, I think EVRP can be more easily
adapted to not require symbolics.
So - can you please re-consider on your EVRP plans? I have no objection
to ditching the SSA propagator VRP pass and ASSERT_EXPRs or to using
ranger from where "on-demand" makes more sense.
So yes, thanks for pointing out this requirement. We will ensure there
is a very fast version that we can use at -O1 or -O0. Maybe that will
be a further adapted version of the current EVRP pass, maybe it will be
something else. And I will add that a high priority item during this
stage 1
We can revisit this in a couple of months when things have settled and
we can get a better view where things stand.
Andrew
