[PATCH] Fix optimization regression in constant folder

[Richard Guenther]

On 9/30/07, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > I tried to bootstrap & test the attached, but it fails in libjava:
> >
> > ../../../../../../trunk/libjava/classpath/gnu/java/awt/font/opentype/truety
> >pe/TrueTypeScaler.java:0: internal compiler error: in fold_overflow_warning,
> > at
> > fold-const.c:1018
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See <http://gcc.gnu.org/bugs.html> for instructions.
>
> The assertion checks that there is no undefined overflow in Java and your
> patch arranges for TYPE_IS_SIZETYPE => TYPE_OVERFLOW_UNDEFINED, so that's not
> very surprising.  The assertion would need to be weakened too.

Yes, I saw this as well.

> > if we really want to specialize sizetypes, then this would be the way to go
> > (after making it work, of course).
>
> Yes, I think that we need to keep them specialized.  However, your patch is
> not sufficient because TYPE_IS_SIZETYPE => !TYPE_OVERFLOW_WRAPS with it so
> the pessimization in fold_binary won't be undone for example.

well, you cannot have both as in...

> It sounds like you really want to have TYPE_IS_SIZETYPE subsumed into the 3
> macros TYPE_OVERFLOW_WRAPS, TYPE_OVERFLOW_UNDEFINED, TYPE_OVERFLOW_TRAPS.
>
> Then I think that we should have
>
>   TYPE_IS_SIZETYPE => TYPE_OVERFLOW_WRAPS
>   TYPE_IS_SIZETYPE => TYPE_OVERFLOW_UNDEFINED
>   TYPE_IS_SIZETYPE => !TYPE_OVERFLOW_TRAPS

...
  TYPE_IS_SIZETYPE => TYPE_OVERFLOW_UNDEFINED
  TYPE_IS_SIZETYPE => TYPE_OVERFLOW_WRAPS
would mean that for sizetype overflow wraps and is undefined at the
same time.  That doesn't make very much sense.

> Note that, in all languages except Ada, size types are unsigned so the first
> assertion is almost already true.  A first step would be to make it true in
> Ada too, which would fix the performance regression in fold_binary.

Yes, IMHO allowing sizetype to be signed is flawed - we have ssizetype
for that (which we don't allow to be unsigned either).

It also doesn't make sense to initialize all the (compiler internal!)
sizetypes from the frontends.  This should be done by the middle-end
instead.  After all, this is _not_ what the languages use for their
size_t.  [IMHO as we use sizetype for POINTER_PLUS_EXPR, the
compiler-internal sizetypes should have the size of the pointers, not
something else]

Richard.