[PATCH] Fix optimization regression in constant folder

[Richard Kenner]

> The rest of don't us really understand what the semantics of sizetypes
> are.  The only documentation is in tree.h, and it only says what
> sizetypes are, it doesn't say what semantics they should have.

Right, because nobody was thinking about these issues back when they
were created.

> In particular I don't understand why sizetypes are sign extended.  Why
> do we have negative sizetype values?

Think about virtual origins for arrays or similar such.  There are a
few cases that come up in Ada where DECL_FIELD_OFFSET (which must be
of sizetype) is a small negative value.

> And TYPE_OVERFLOW_WRAPS is not quite sufficient, since it does not
> permit canonicalizations.
> 
> TYPE_OVERFLOW_WRAPS seems clearly correct for sizetypes (if not, why
> not, and give us an example).

For the reason you just gave: it suppresses some optimizations.

> So it seems that we should do is separate TYPE_OVERFLOW_UNDEFINED into
> two different meanings:
> 
> 1) We can assume that computations in this type will never overflow,
>    but we should be careful not to introduce overflow where it was not
>    present.  (TYPE_OVERFLOW_UNDEFINED)
> 
> 2) We can assume that computations in this type will never overflow,
>    no matter what we do.  (TYPE_IGNORE_OVERFLOWS)
> 
> Then a few places which currently check TYPE_OVERFLOW_WRAPS can check
> TYPE_IGNORE_OVERFLOWS instead.

That would probably work.

> I really want to move toward a semantics for sizetypes which does not
> involve mysterious checks for TYPE_IS_SIZETYPE.  If we can't do that,
> we are going to keep breaking the way you want it to work.

I see it exactly the opposite way around: sizetype means "handle this
computations in the most efficient way possible" (like my EXACT_DIV_EXPR).
So any optimization conditionalized on an attribute of the type can simply
can "|| TYPE_IS_SIZETYPE".  But if we go the approach of defining flags in
a special way to deal with case and then get rid of TYPE_IS_SIZETYPE, we 
have to go through exactly the same problem as now if some other 
attributes are added to types that suppress only some optimizations.