GCC Status Report (2004-03-09)

[Mark Mitchell]

Eric Botcazou wrote:

>>I'd particularly like to understand this RTX_UNCHANGING_P optimization
>>issue.  We've bumped into this before.  I think we need to take the
>>conservative approach, even if that is pessimizing in some case.
>>Would someone who understands the details of this bug please summarize
>>it, mail that to me, and also add that information to the appropriate
>>PR?
>>    
>>
>
>The problem is related to the semantics of the /u flag on memory writes.  
>Strictly speaking, the /u flag should be put only if the memory location is 
>guaranteed to be ever written once.
>  
>
Thanks for this summary.

>Third problem: now, on the 3.4 branch, if the whole structure contains 
>read-only fields and read-write fields, is wholly cleared and at least one 
>read-write field is set to non-zero, we have a memory write with the /u flag 
>followed by a memory write without the /u flag.  These of course don't 
>conflict so may be swapped by the scheduler (this is my testcase on 
>UltraSPARC for PR opt/13424).
>  
>
>A solution (by Olivier Hainque, that is now in the ACT tree) is to disable 
>the clearing optimization in the unsafe cases, that is when we know that 
>another write may be issued later which will not conflict
>
The other alternative I can think of is to introduce a scheduling 
barrier (e.g., a dummy vaolatile asm) after the clearing operation.  I 
don't know which of these alternatives would lead to greater 
pessimization.  I think the scheduling barrier approach might actually 
be better, but I can't justify that very well.

So, would you please apply Olivier's patch to the 3.4 branch and the 
mainline?  Then, we need to come up with some better long-term solution.

Thanks,

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com