[PATCH] Fix optimization regression in constant folder
Ian Lance Taylor
iant@google.com
Wed Oct 3 07:00:00 GMT 2007
Eric Botcazou <ebotcazou@adacore.com> writes:
> > 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)
>
> Yes, TYPE_IGNORE_OVERFLOWS is what I'm asking for from the very beginning.
>
> > Then a few places which currently check TYPE_OVERFLOW_WRAPS can check
> > TYPE_IGNORE_OVERFLOWS instead.
>
> What about places where we check TYPE_OVERFLOW_UNDEFINED? Or do we keep
> TYPE_OVERFLOW_UNDEFINED on size types too (it is set for Ada)?
In some of the places where we currently check
TYPE_OVERFLOW_UNDEFINED, we would also check TYPE_IGNORE_OVERFLOWS (or
we introduce yet another flag which is the intersection). In the
proposal above, it doesn't make sense to me to set
TYPE_OVERFLOW_UNDEFINED for sizetypes.
Ian
More information about the Gcc-patches
mailing list