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


> 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.  But they *are not* user-visible types,
so I don't think of them in those terms.

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.

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

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

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

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, for numerous reasons (among them being
tree consistency checking: making sure that the appropriate tree operands
are always sizetypes).


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