This is the mail archive of the gcc-patches@gcc.gnu.org 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


Hi,

On Thu, 11 Oct 2007, 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,

Yesterday?  I don't see such agreement anywhere.  It would be nice to have 
this agreement, but the last time we really talked about the semantics of 
sizetype was on October 4. and there Ian proposed to have 
TYPE_IGNORE_OVERFLOWS at all, and Eric proposed TYPE_IGNORE_OVERFLOWS + 
TYPE_OVERFLOW_WRAPS for sizetypes 
(http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00177.html).

But the justification for the validity of TYPE_IGNORE_OVERFLOWS on 
sizetype follows from "negative values have small magnitude".  If we don't 
have this justification (and I don't see that we have it), only 
TYPE_OVERFLOW_WRAPS can stay.

And I would agree that yes, this is a usefull property of sizetype.

But if that is the only justifieable property of sizetype, why not use a 
type which naturally has this property, like some unsigned type?

> 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.

Depends on if you agree to the above or not.  If you agree (and you seem 
to) that the important thing is wrapping overflow, I'm also going to say 
that sizetype should not be allowed to be a signed type.


Ciao,
Michael.


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