This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix optimization regression in constant folder
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?
(650) 331-3385 x713