Sorry for the breakage, we need to continue processing EH edges..

Bootstrapped on x86_64-pc-linux-gnu (including Go :-)  with no 
regressions as of the original checkin.   I hope this catches all the 
other ripple PRs too.  Pushed.


> Returning NULL in gimple_range_ssa_p is probably not a good idea.  The
> name does carry a range it just has to be considered VARYING.
>
> The issue with abnormal edges is that they do not have a jump
> associated with them and thus we cannot insert code on the edge
> because we cannot split it.  That has implications for coalescing
> since we cannot even insert copies there so the PHI argument
> and the PHI result have to be the same register for the arguments
> on abnormal edges.
>
> Otherwise they do carry a value and a range but forcing that to be
> VARYING makes sense to avoid propagating constants to where
> it is not allowed (though the substitution phase should be the one
> checking).

gimple_range_ssa_p is mean to be more of a gateway into processing.  If 
its false, we wont try to find any additional range for it.  This keeps 
it out of the tables and caches, reducing processing time as well as the 
memory footprint.

We can find ranges for anything with supports_type_p() set to true,and 
it is likely to be VARYING if gimple_range_ssa_p is false now.

That said, this is the first time is been super heavily exercised in 
this regard, and there are a couple of places where we were returning 
FALSE which was less than ideal.   I should have been calling 
get_tree_range, which would then return false for non-supported types, 
or the global/varying value if they are.

And we could probably do better for at least calculating a range for 
such SSA_NAMES under these circumstances.. there is no reason we can't 
fold the stmt an get a range.  I'll tweak/audit  that in a follow up so 
there is better consistency between when we check gimple_range_ssa_p and 
irange::type_support_p()


Andrew