This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Status Report (2004-03-09)
Eric Botcazou wrote:
Well, so, let's remove that chunk of code; it should no longer be needed.
Do you want me to revert that patch?
Yes -- if your tests confirm that it is safe to do so.
Eric, I can tell you're unhappy with this approach, and so you're
casting about for something better. That's good, but I think we've come
as far as we can for 3.4.0.
Yes, I'm pretty frustrated because we're (again) chasing down a far-reaching
bug just days before a release.
Yes. This bug has been lying around for a long time, and we were all
afraid to tackle it. The long-term solution is clearer interfaces and
specifications so that it's more obvious what's wrong; the problem here
is that none of us quite know what this code is supposed to do.
Before I start thinking about a replacement, I'd like to understand what I'll
be trying the replace. It appears that no-bo-dy can tell what is the
purpose of RTX_UNCHANGING_P.
It's supposed to be the RTL equivalent of "const". In other words, once
initialized, an RTX_UNCHANGING_P thing is immutable, and therefore no
writes can alias it. If you're after the one write to the
RTX_UNCHANGING_P thing, then it's value is always valid. That's true
even if someone has its address; they cannot write through the pointer.
This is clearly a valuable optimization aid. I think that simply making
this flag a tri-state will be the cleanest fix. For memory to which
this clearing optimization applies, the flag should not be set, because
the memory is written twice. If we're worried about pessimization in
that case, we should avoid writing the memory twice.
Frankly, I suspect that there is virtually no real code where writing
only to the holes (where "holes" means "fields that are not explicitly
initialized to a non-zero value, and, if the compiler so desires, parts
of the object that are not part of any field") has any observable
performance from clearing the whole structure. If most of the structure
is zero, then that will certainly be true. If only a tiny bit of the
structure is non-zero, that will certainly be true. If the non-zero
parts are contiguous, that will probably be true. In practice, there
are few inner loops involving initializing every other field in a
structure, and that is the case where we would lose.
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com