Re: [PATCH] Fix optimization regression in constant folder

[Ian Lance Taylor <iant at google dot com>]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> > You say you need special semantics because otherwise optimization won't work.
> 
> Actually, I didn't say that.  I said that sizetypes *already have* and
> always have had different semantics than user-visible types and that trying
> to map those semantics onto a new set of semantics being defined for
> user-visible types is not correct.

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.

That is why we must have test cases.  If we don't have test cases, we
will certainly break those semantics going forward.  We don't need
description, we need code.

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


That said, I take your point that TYPE_OVERFLOW_UNDEFINED is not quite
right for sizetypes, since it does not permit us to introduce overflow
where it was not present (i.e., it does not permit us to reassociate).
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).

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.


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.

Ian