Re: [PATCH] Fix optimization regression in constant folder

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 10/1/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > I see exactly 6 places in the middle-end that check TYPE_IS_SIZETYPE.  All
> > of them in fold-const.c.  What I say is that if sizetypes are worth to
> > be special for optimization, why don't optimization passes like VRP or =
> > tree-ssa-reassoc.c not check for TYPE_IS_SIZETYPE?
>
> Do they check for overflow properties?  If not, why should they check for
> sizetype: the only difference is overflow properties.

Sure they do.  tree-ssa-reassoc.c does, err, re-association, which is only valid
for wrapping overflow (or as you define it, for sizetypes).  VRP
simplifies things
based on for example undefined overflow.  In _most_ of the cases the middle-end
now checks via the appropriate TYPE_OVERFLOW_* macros, but there are
probably places left that just use TYPE_UNSIGNED to decide on overflow
behavior.

Which is why, if at all, sizetype should be specialized in the overflow checking
macros, because then a lot more optimizations benefit from it.  Instead they
now change optimization behavior on sizetypes based on their sign, flag
setting such as -fstrict-overflow or -fwrapv, which clearly does not match
not exposing sizetype semantics to the user.

> > You seem to have a testcase that shows that re-association is very important
> > for you for sizetypes.  Why can't you produce something out of it that you
> > can show us?
>
> I think Eric is working on that (these tend to be very large test
> cases), but that's orthogonal to the definitional issue here.

Thanks,
Richard.