This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
On 10/1/07, Richard Kenner <firstname.lastname@example.org> 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
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
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.