Re: [PATCH] Fix optimization regression in constant folder

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

> Not at all.  I'm thinking in middle-end operations possible on those types.

So am I.  They are used to define the sizes of objects and offsets into
objects in the middle-end and I agree that it's important to get well-defined
semantics for them. 

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

Somewhat, though I'm trying hard not to define the sizetype semantics in
the same way we would for a user-visible type since it *isn't* user-visible.
It would be *close* to that, except that this will suppress critical
optimizations that must be done for sizetypes.

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

We supress reassociation.  For a type with undefined overflow, we can't
convert (a + b) + c into a + (b + c) for fear of the latter expression
overflowing where the former couldn't.  However, this can only very rarely
happen in practice and only in circumstance I'm calling "pathalogical",
where A and B have opposite signs, both are large, and where B and C have
the same sign.  But this just can't come up in size and offset computations:
any negative values are always small.

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

See below.

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

This is what I meant.

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

And that, I think, is the problem.  They should not apply to sizetypes
since sizetypes have a unique semantics that we don't need to express in
terms of those flags.  For each optimization that we want to supress for
some values of those flags we say we do it for some setting of those
flags *or* if the type is a sizetype.

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

It's not "front end semantics", but an implemenation issue.  Sizetypes
aren't visible at the user level for Ada either.

> You need to find a mapping from whatever frontend types you have to
> the middle end types.

Of course, but sizetypes are *never* visible at the language level and are
*only* used to communuicate size and position information to the middle-end,
so I lost you here.