From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1552 invoked by alias); 19 Mar 2004 18:48:18 -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 1480 invoked from network); 19 Mar 2004 18:48:17 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.6) by sources.redhat.com with SMTP; 19 Mar 2004 18:48:17 -0000 Received: (qmail 3775 invoked from network); 19 Mar 2004 18:48:16 -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; 19 Mar 2004 18:48:16 -0000 Message-ID: <405B4073.5000105@codesourcery.com> Date: Fri, 19 Mar 2004 20:23: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: Jakub Jelinek , gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: GCC Status Report (2004-03-09) References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <200403191413.10043.ebotcazou@libertysurf.fr> <405B302B.40006@codesourcery.com> <200403191934.34104.ebotcazou@libertysurf.fr> In-Reply-To: <200403191934.34104.ebotcazou@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg01162.txt.bz2 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