Re: [PATCH] Fix optimization regression in constant folder

["Richard Guenther" <richard.guenther@gmail.com>]

On 10/1/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > It matches undefined overflow && wrapping overflow, as for infinite precision
> > overflow really cannot happen.
>
> But it can happen: in the case of illegal programs when the programmer tries
> to make an object that's too big.
>
> > 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.
>
> > This needs testcases.
>
> Eric and I have both given you an example of an optimization that should
> apply to sizetypes but which won't if you try to change their semantics to
> match those of a user-visible type.
>
> > Otherwise just mapping sizetype semantics to an _existing_ semantic makes
> > most sense as it reduces diversity of semantics and causes less
> > confusion.
>
> I'm not proposing changing the semantics of sizetypes!  Quite the contrary:
> I'm saying that we keep them as they are and *not* try to map them to these
> new flags which are meant for user-visible types.
>
> > Look at all the places we _don't_ specialize sizetypes!  You want to audit
> > all these?
>
> I don't follow.  All these optimizations used to be done for sizetypes and
> I'm saying they need to continue to work.  It's the proposal to use these
> new flags that's changing things.  And I also don't understand what "audit"
> means in this context.  The semantics of these various types (sizetypes and
> the different user-visible type semantics) only differ in overflow
> handling.  So we only need to "audit" those cases where overflow tests are
> involved.

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?  I say, that TYPE_IS_SIZETYPE can't
be very important as its only used in _very_ few places.  Instead I
ask for testcases
where it _matters_ that we do the optimization in the few places in fold-const.c
that check for TYPE_IS_SIZETYPE because no other optimization pass does
the required transformation.  I argue we should fix optimization passes instead
of fold.  Or if you rely on sizetype in a so different way in Ada than other
frontends maybe using fold () to simplify sizetype operations is not the best
way to ensure proper optimization?

Two of the 6 places are to check if sizetypes are sign-extended, one is to not
mark results TREE_OVERFLOW in int_const_binop for sizetypes.  One is in
extract_multdiv_1 and it needs a comment - it's not exactly clear why sizetype
is special here.  One is with widening which is somehow special for sizetypes,
one is for optimizing div/mult sequences.  That's it.

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?

Richard.