This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix optimization regression in constant folder

On 10/11/07, Richard Kenner <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]