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 Sun, 30 Sep 2007, Richard Kenner wrote:

> > Right.  A type can be neither.  But you were asking for sizetypes to
> > be both, and that does not make sense.
> No, the claim is that a sizetype can *act like* both and that's different.

Clearly a type can not be both at the same time, no matter how much you 
want.  I think the problem comes from the fact that we can use those 
type predicates for different things, namely to 1) infer some knowledge 
about past operations on values of that type (which in turn then might to 
lead to other transformations), and 2) guide which operations we allow on 
values of this type (e.g. that we have to add overflow checks or not).

>From what Eric and you told us up to now it seems you want this type to 
have the following properties:
1) overflows don't occur (because you make sure that the compiler never 
   produces overflows on such values)
2) if overflow were to occur, then it wraps (given the first 
   property this is weird, but that is what you said)
3) you want to optimize based on both assumptions, i.e. that overflow
   can't occur, and that the type has wrap-around

I think you need to make up your mind about the property (2) above: why 
_exactly_ (meaning test situations) do you care for how overflow happens 
if you already defined that it can not happen.  Everything will follow 
from that.

What I think you should want is that the type is simply an unsigned type, 
with overflow undefined.  But given the internal inconsistency in your 
current wishes I can't be sure if that really solves your problems.

An unsigned type with undefined overflow does have a place in a 
middle-end.  A type with your current conflicting semantics does _not_ 
have a place in the middle-end IMHO, so it's time invested very well in 
thinking hard about your exact requirements.

> You can't capture that concept with flags that talk about 
> language-defined concepts such as undefined overflows or wrapping 
> because sizetypes are *not* language-defined but internal.

The type flags reflect (or better are meant to reflect eventually) 
properties for the middle-end type system.  Languages types are required 
to map to those we have (of course we can increase the set of properties 
of middle-end types).

It's true that the type flags still are pretty much coming directly from 
language semantics, simply because the middle-end type system is in its 
infancy.  But it will change in one or the other way (cross language LTO 
needs that), and it would be better if it's a well thought out way.  
That's why this discussion is important.  So, if the middle end would give 
you an unsigned, overflow undefined type, would that satisfy you (at least 
when the optimization you want to happen on them, do happen then, which 
also requires some example situations from you)?


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