Instead of defaulting to an initial value of VARYING before resolving 
cycles, try folding the statement using available global values 
instead.  THis can give us a much better initial approximation, 
especially in cases where there are no dependencies, ie
    f_45 = 77

This implements suggestion 2) in comment 22 of the PR:

    2) The initial value we choose is simply VARYING. This is why 1)
    alone won't solve this problem.  when we push _1947 on the stack, we
    set it to VARYING..  then proceed down along chain of other
    dependencies Driven by _1011 which are resolved first. When we get
    back to _1947 finally, we see:
       _1947 = 77;
    which evaluated to [77, 77], and is this different than VARYING, and
    thus would cause a new timestamp to be created even if (1) were
    implemented.

    TODO: When setting the initial value in the cache, rather than being
    lazy and using varying, we should invoke fold_stmt using
    get_global_range_query ().   This will fold the stmt and produce a
    result which resolved any ssa-names just using known global values.
    THis should not be expensive, and gives us a reasonable first
    approximation.  And for cases like _1947, the final result as well.

I stop doing this after inlining because there are some statements which 
change their evaluation (ie, BUILTIN_IN_CONSTANT)  which causes 
headaches... and then we  just default to VARYING again or anything 
which doesn't have a  global SSA range set..

There is a 2.7% hit to VRP to evaluate each statement this additional 
time, but only 0.09% to overall compile time. Besides, we get it back 
later in the patch set.. :-)

Bootstraps on x86_64-pc-linux-gnu with no regressions.   Pushed.

Andrew