This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
On 10/11/07, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
> > Yes I understand that. But what we have to do in the middle-end from C++
> > constructs like Mark has shown has to be done in a type which does not
> > have the ignore_overflow "semantic" (because the justification for that
> > semantic, namely negative values have small magnitude simply doesn't
> > hold). In fact the most natural choice for a type to calculate that
> > expression would have been unsigned because that allows all rearrangements
> > of the operands. But when the natural type for doing arithmetics on such
> > operands is type X it simply doesn't make sense to store those operands as
> > having type Y, as conversions would be required all the time we actually
> > look at the operands.
>
> But I thought that we agreed yesterday that, unless there are some surprises
> coming from givs in loop optimization, we should treat sizetypes as
> wrapping on overflow, whether signed or unsigned. So I'm not sure what you
> mean above.
>
> Certainly the point is to do the entire sizing computation in ONE type
> and not convert back and forth: that's the whole point of sizetype!
Yes - one excercise we should carry out is to put in place some checks that
we only convert _to_ sizetype, but never _from_ it. The only place we go
"backward" is using POINTER_PLUS_EXPR which doesn't require an
explicit conversion. Of course there might be optimization passes
that propagate
the offset from POINTER_PLUS_EXPR in interesting ways back to user-visible
integer types - think of &a[i] - &a[j] which we even fold to i - j (of
user integer
type, that is). So I don't really think such a check is practical.
Richard.