[PATCH] Fix lazy value info computation to improve jump threading fora common case

[Nuno Lopes]

I'm concerned about loops.
Are you sure the algorithm will terminate when you ask for the range of a 
recursive phi value?
Something like this:

entry:
br label %bb1

bb1:
%a = phi [%a %bb1, %b %entry]
br i1 %cond, label %bb1, %bb2

bb2:
  <get range of %a>


Apart of that, for compile-time reasons, you'll probably have to limit the 
maximum path length.  Otherwise you risk crawling thousands of BBs.

Nuno

----- Original Message -----
> Hi,
>
> Attached patch is to fix an issue in lazy value info computation, and
> finally it can improve jump threading for a common case.
>
> Lazy value info computation algorithm tries to use lattice to propagate 
> the
> given value through control flow. The problem of the algorithm is the 
> basic
> block can only be visited once. Once the lattice state is changed from
> "undefined" to other states, the lattice state will be cached, and won't 
> be
> able to be changed any longer.
>
> For the following simple control flow graph like below,
>
> BB1->BB2, BB1->BB3, BB2->BB3, BB2->BB4
>
> When computing a given value on edge BB2->BB3, if B2 doesn't have that
> value info at all, the algorithm will try to ask for information from 
> BB2's
> predecessors, and then return to BB2 again to merge the info from
> predecessors, so BB2 will be visited twice. Unfortunately, at first visit
> of BB2, the lattice state will be changed from "undefined" to
> "overdefined", and then it will not be able to be changed any longer.
>
> This patch is to simply check "overdefined", and make sure the algorithm
> can still move on to propagate the values from predecessor edges to the
> block itself.
>
> The performance experiment for spec shows pretty good result on aarch64 
> for
> this fix, and the 253_perlbmk can even have >5% performance improvement.
>
> Thanks,
> -Jiangning