From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18868 invoked by alias); 16 Mar 2004 16:53:37 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18859 invoked from network); 16 Mar 2004 16:53:34 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.6) by sources.redhat.com with SMTP; 16 Mar 2004 16:53:34 -0000 Received: (qmail 21286 invoked from network); 16 Mar 2004 16:53:29 -0000 Received: from 227.148-60-66-fuji-dsl.static.surewest.net (HELO codesourcery.com) (mitchell@66.60.148.227) by mail.codesourcery.com with SMTP; 16 Mar 2004 16:53:29 -0000 Message-ID: <40573108.4080602@codesourcery.com> Date: Tue, 16 Mar 2004 16:53:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Eric Botcazou CC: gcc@gcc.gnu.org Subject: Re: GCC Status Report (2004-03-09) References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <200403111030.14616.ebotcazou@act-europe.fr> In-Reply-To: <200403111030.14616.ebotcazou@act-europe.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00823.txt.bz2 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