GCC Status Report (2004-03-09)

[Mark Mitchell]

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