Re: [COMMITTED 4/4] - Gimple range PHI analyzer and testcases

[Andrew MacLeod <amacleod@redhat.com>]

On 5/25/23 03:03, Richard Biener wrote:
> On Wed, May 24, 2023 at 11:21 PM Andrew MacLeod via Gcc-patches
>
>
>    There is about a 1.5% slowdown to VRP to invoke and utilize the
> analyzer in all 3 passes of VRP.  overall compile time is 0.06% slower.
>
> Bootstraps on x86_64-pc-linux-gnu  with no regressions.  Pushed.
> Hm.  What I've noticed the last time looking at how ranger deals
> with PHIs is that it diverts to SCEV analysis for all of them but
> it could restrict itself to analyze PHIs in loop headers
> (bb->loop_father->header == bb).  That only handles natural
> loops of course but that was good enough for the old VRP implementation.
> That might also help to keep the PHI anlyzer leaner by less entires.

>
> I've only quickly looked at the PHI analyzer and I failed to understand
> how you discover cycles.  I'm pointing you to the SCC value-numbering
> cycle finding which you can find for example on the GCC 7 branch
> (it's gone for quite some time) in tree-ssa-sccvn.c:DFS - that collects
> strongly connected SSA components (it walks all uses, you probably
> want to ignore virtuals).  SCEV also has its own cycle finding
> (well, sort of) with the scev_dfs class and it restricts itself to
> operations it handles (so it's more close to what you do).
>
> I fear you're developing sth very ad-hoc here.
>
Not something Ad-hoc in this compiler!

This is primarily an initial value estimator.  There is no attempt to do 
any loop analysis or anything like that.

It doesn't look for cycles per se, merely PHI nodes which feed each 
other and are modified in a straight forward way.. ie initialized on one 
edge and modified via one statement that we can then look at to decide 
how it affects the range of all the PHI nodes. This can eventually be 
changed to a sequence of a few statements, but one gets us started with 
the simple cases. All the rest of the PHI arguments come from PHI nodes 
and share the same value.  This can allow us to project a range which is 
better than VARYING.  SCEV doesnt seem to help much in these cases.

  It's pretty straightforward which is why it isn't much code. all 
handled in  phi_analyzer::process_phi().   Add phi node to worklist, 
examine each argument, if it iis a PHI def, add it to the worklist  if 
it hasnt been processed, otherwise, its an external input to the group, 
and bail if we get more than 2 of these.

Andrew

Andrew