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

[Michael Matz <matz at suse dot de>]

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.

So, if the frontend _does_ want to define its semantics in a way that 
valid() may return false, then it needs to make this explicit by doing the 
comparison in the base type, and adding proper conversions (and as we know 
it needs  to be VIEW_CONVERT_EXPR).  Though this will get a bit 
complicated, because when we only look at the body:

> bool valid(E v) { return v >= E_MIN && v <= E_MAX; }

then the frontend must somehow make sure that the middle-end can not 
assume that the input 'v' is indeed in the range of its declared type.  
I'm not sure how to do that, a conversion is not enough (as the incoming 
invariant is already broken), maybe it needs to setup the representation 
in a way that the incoming type does not have a constrained range.  Hmm.
It seems I'm now saying the same thing as Paolo, namely that the C++ 
frontend may not set MIN/MAX of enum types.  Strange... :-)


Ciao,
Michael.