This is the mail archive of the
mailing list for the GCC project.
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.
> 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.