This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
On Mon, 1 Oct 2007, Richard Kenner wrote:
> I'm not trying to figure out a way to make things work now, but to establish
> a framework for the future. The semantics of sizetypes mean "don't
> suppress *any* optimizations".
Let me show you why the predicate "don't suppress any optimizations" is
non-sensical by a constructed example: Suppose we were to introduce a type
flag which can be applied to integral types ensuring that all values of
that type are even integers, TYPE_EVEN_VALUED.
Presumably we did so because we saw the need for some worthwhile
transformation applied to such values. For instance we could use the low
bit for something else, or increase the range of that type to be twice the
nominal range. Let one of these transformations be an optimization.
You are probably not going to argue that such optimization should also be
applied to your sizetype. Hence "all" optimizations is a useless
predicate. You need to spell out what operations are allowed on that
type, and what the invariants for them are. There really is no way around
this. Because otherwise someone somewhere will break what you think the
semantics of it should be, but neglected to specify.
So, there's your path to the future, ensuring nobody will break your
wishes; spell out what operations are required for your type. To make
that easy start with the most similar existing type (probably signed
integer), and say what the new invariants of operations are. Then destill
those invariants (or better the diff to the invariants from the starting
type) to a small set of orthogonal properties which can then be flags on
types (and perhaps that will simply lead to only the IGNORE_OVERFLOW from
Ian). TYPE_IS_SIZETYPE is not such element of an orthogonal set of