PATCH COMMITTED: Don't break tests for enum in range

[Richard Guenther]

On 6/6/07, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Wed, 6 Jun 2007, Paolo Bonzini wrote:
>
> > > > No, I think on the contrary that TYPE_MIN/MAX_VALUE *is* a useful
> > > > thing to have in the middle-end.
> > >
> > > For what, if we don't want to do optimization based on it?
> >
> > We don't *always* want to do optimization based on it.
>
> That's a strange statement, either we want to do optimization based on
> them (and I'm of that opinion), or we don't.  If we want to then we need
> to set them to sensible values, hence your suggestion to _not_ set MIN/MAX
> for enums seems to imply that you do not want to optimize based on that,
> i.e. you contradict yourself :-)
>
> Now, if we were to make use of MIN/MAX in vrp to the full extent possible,
> then indeed for this example:
>
> > enum E { V = 1 };
> > static const E E_MIN = V;
> > static const E E_MAX = V;
> > bool valid(E v) { return v >= E_MIN && v <= E_MAX; }
> > int main() { return valid(E(2)); }
>
> (let's read this as pseudo code, not using C or C++ semantic) then vrp may
> validly assume that the valid() predicate is true all the time.  It may
> assume that because the type in which the compare happens is 'E' (because
> all operands, even 'v' is of that type), so it's a tautology.
>
> I'm not sure why Ian thinks that vrp (properly extended to make
> really use of MIN/MAX) would draw the conclusion that valid might ever be
> false.

I think what will happen is that valid() is inlined and we const-prop the 2
(as a integer constant node with a value that is outside of its range ....
(yep, fold regularly does that)) and we'll fold/simplify it based on
the constant
operations.

Note that VRP only derives ranges from conversions, not from "initial type".
And for conversions only, if the conversion changes precision (we'll break
ada otherwise), but then using min/max value.

Richard.