This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]