Re: GCC Status Report (2004-03-09)

[Mark Mitchell <mark at codesourcery dot com>]

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