Improve VRP, remove DOM nonzero property tracking

[Laurent GUERBY]

Hi Jeff,

Ada bootstrap is now failing on a RTS file at -O2 and the file
compilation works at -O1 but fails at -O1 -ftree-vrp (failure
beeing eating up all RAM then SEGV).

I opened a PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348

I haven't tested if r111170 works and if r111175 fails
but from the ChangeLog your patch is an easy suspect :).

Laurent

On Thu, 2006-02-16 at 21:14 -0700, Jeffrey A Law wrote:
> Here's the next installment in ripping out those bits in DOM which
> are implemented better elsewhere in the compiler.
> 
> This installment removes DOM's non-null tracking code (basically just
> a special case of VRP).  However, as has been the case with just about
> everything so far it's not that simple.
> 
> While evaluating the codegen impact of this change I ran across some
> trivial cases that DOM would catch that VRP would not.  They weren't
> really null pointers, but expressions which produced nonzero results
> X = (A | 1)  is the trivial example.  No matter what the value of A
> is, we know that X will have a nonzero value.
> 
> The closer I looked at VRP the more I realized that were missing a
> *ton* of easily discoverable nonzero and nonnegative ranges.   The
> best way I could see to solve the problem was to let the existing
> VRP code try to discover ranges.  If that failed (VR_VARYING), then
> allow VRP to query some existing generic code in fold-const.c
> (tree_expr_nonnegative_p, tree_expr_nonzero_p).  However, to get
> maximal value from this change we also allow the fold-const.c routines
> to query VRP for any range information it might have about a specific
> SSA_NAME.
> 
> That (of course) exposed a handful of latent bugs in the fold
> routines, VRP, and the annoying sizetype maximum value bug.  With
> those problems resolved, I can finally install this patch :-)
> 
> 
> Bootstrapped and regression tested on i686-pc-linux-gnu.
> 
>