Re: Add overflow infinity handling to VRP

[Jan Hubicka <hubicka at ucw dot cz>]

> VRP currently uses TYPE_MAX_VALUE and TYPE_MIN_VALUE as infinity.
> However, it is somewhat vague about the notion of overflow.  For
> example, if a range has a max of TYPE_MAX_VALUE, and VRP subtracts 1,
> the max will become TYPE_MAX_VALUE - 1.  That is not appropriate if
> the max was set to TYPE_MAX_VALUE due to a signed overflow.  (It is
> also possible that this might lead VRP to an incorrect conclusion in
> some cases, although I didn't try to prove that.)
> 
> This ambiguity makes it difficult to correctly issue warnings when
> optimizations rely on the fact that signed overflow is undefined in
> standard C.  For example, the range introduced by an "i > 0" assertion
> needs to be handled differently from the range introduced by a loop
> which increments i.  The latter is an overflow condition where the
> former is not.
> 
> This patch changes VRP by introducing a notion of an overflow
> infinity.  The overflow infinity value is used when an operation
> overflows.  The positive (negative) overflow infinity for a type is
> simply a copy of the TYPE_MAX_VALUE (TYPE_MIN_VALUE) for the type.  We
> use a small hash table to pick up the overflow value.

Perhaps there is not a better way around, but I am bit concerned about
making operand_less_p more complicated via all the inline magic.
What compile time effect does the patch have on compile/20001226-1.c ?

Honza