Re: [PATCH] Fix optimization regression in constant folder

[Mark Mitchell <mark at codesourcery dot com>]

Richard Kenner wrote:

> The problem is that all I can do now is offer an *operational* definition,
> so it would be "... except that all the operations on it are generated by
> the compiler as part of computations of sizes and offsets so that we can
> prove certain properties of those expressions that would not be true for
> integer types in more general usages".
> 
> Yes, it might be nice to enumerate that list of properties, but I don't see
> it as critical that we do so, since instead we can just ask the question
> for each case (optimization) that comes up. 

I don't think that's good enough.  If we can't specify this better, then
I suspect that, over time, it's going to break, and people will
eventually just rip it out.  So far, we've got no test cases and no
explanation of the semantics.  So, I don't think you should be surprised
if the middle-end maintainers decide they don't understand the point and
replace it with, essentially, the user-level size_t.

That's going to hurt Ada hardest because in C/C++, there aren't very
many run-time computations involving sizes; most of what we do with
sizes is folded away at compile-time, or is converted from sizetype to
the user-level size_t anyhow.  (For example, calling an inline C++ new
operator converts to size_t before doing the inlining, so any
computations on the size done within the body of the operator are going
to be done on the user-level type, and optimization limitations that
apply to ordinary unsigned integer types will end up applying here too.)

The only place I can actually see uses of TYPE_IS_SIZETYPE are
fold-const.c and tree.c.  And, in both cases, it looks like we do
exactly one thing: treat sizetypes are sign-extended even when
TYPE_UNSIGNED.  That begs the question: why aren't they signed, or why
do we care about bits outside their precision?  Where are the extra
optimizations happening that you're talking about?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713