This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH COMMITTED: Don't break tests for enum in range
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.