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:

> > 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)
> No, that's wrong.  As I said, the above is thinking in terms of them
> as if they were types visible to the user and you are thinking in
> programming language terms.

Not at all.  I'm thinking in middle-end operations possible on those 
types.  I don't care for front-end semantics (to the extent that a mapping 
must be reasonably possible), only what needs to be done by the 
middle-end, what it can assume, what it needs to ensure.

> Sizetypes have always had the the following properties:
> (1) They can only overflow in a case where the program is clearly illegal:
> e.g., where the programmer is attempting to construct an object whose size
> is larger than can be represented by the machine being coded for.

Okay, so overflow can not happen (except in illformed programs, in which 
case we don't need to care).  That seems to hint to a OVERFLOW_UNDEFINED 

> (2) Computations on sizetype are "well behaved" in the sense that they do
> not contain pathalogical cases that require us to supress some optimizations
> on other integer types.

Be more specific.  Much more.  What pathological cases, what optimizations 
do we suppress currently, which of those are allowed in your system.  What 
properties of the type guarantee this.

> > 3) you want to optimize based on both assumptions, i.e. that overflow
> >    can't occur, and that the type has wrap-around
> More precisely, you want to do *all* optimizations.

Too unspecific.

> For what I'll call "user-visible" types, you may need to restrict 
> certain optimizations to only those types that has some particular flag 
> bits relating to overflow semantics, but for sizetypes, you *always* 
> want to do each of them.

But we don't talk about user-visible types.  I never did, and it seems you 
also don't want to talk about them, so let's not do that :-)  As I tried 
to express already, the flag bits are _not_ only for user-visible types.

That this type isn't user-visible doesn't relieve us from defining exactly 
what (middle-end) operations are defined on it, though.  That's what we 
ask from you with at least providing some test situations where an 
unsigned overflow-undefined type doesn't help.

> > What I think you should want is that the type is simply an unsigned type, 
> > with overflow undefined.  
> (1) sizetype in Ada needs to be signed.

That's frontend semantic then, which you explicitely did not want to get 
into.  So why do you say that?  You need to find a mapping from 
whatever frontend types you have to the middle end types.  _If_ 
that mapping is too suboptimal we might have to extend the middle-end 
types.  But consistently so.

> (2) if overflow is viewed as undefined, there are optimizations that we
> would be suppressed but we want to suppress *none* of them.

Like?  For now I only see optimizations enabled by 

> But I don't understand why we need (or want!) to define sizetypes in terms
> that we'd use for user-visible types: they *aren't* user-visible types,
> but instead are very special types used for very specific purposes in
> the compiler.  Trying to treat them as if they were user-visible types
> seems *very* wrong to me,

I really have a hard time understanding why you're so obsessed (sorry) 
about the user-visible thingy.  Nobody is talking about that.  We are 
talking about the semantic of the middle end sizetype type.  At least I am 
(I'm 99.9% sure Richard G. is, and reasonably sure Ian is too), only you 
keep talking about it.


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