From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18674 invoked by alias); 18 Mar 2004 18:46:34 -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 18645 invoked from network); 18 Mar 2004 18:46:33 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.6) by sources.redhat.com with SMTP; 18 Mar 2004 18:46:33 -0000 Received: (qmail 24423 invoked from network); 18 Mar 2004 18:46:32 -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; 18 Mar 2004 18:46:32 -0000 Message-ID: <4059EE8A.4060407@codesourcery.com> Date: Thu, 18 Mar 2004 19:15: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, gcc-patches@gcc.gnu.org Subject: Re: GCC Status Report (2004-03-09) References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <405874AD.2010709@codesourcery.com> <200403180924.19533.ebotcazou@libertysurf.fr> <200403181927.00513.ebotcazou@libertysurf.fr> In-Reply-To: <200403181927.00513.ebotcazou@libertysurf.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg01076.txt.bz2 Eric Botcazou wrote: > 2004-03-18 Eric Botcazou > Mark Mitchell > > PR optimization/13424 > * expr.c (store_constructor): Emit a blockage after clearing the > aggregate because of an incomplete or mostly zero constructor if > the aggregate contains read-only fields. > > >But this would still pessimize a lot, because life analysis would not be able >to delete the redundant writes anymore. > > We could only zero out the "holes" between the fields. That would be slower than zeroing the hole thing at once, but usually not much, especially since memzero will be inlined for small chunks of memory. We could also disable the use of RTX_UNCHANGING_P in alias.c. We could make RTX_UNCHANGING_P a tri-state (with a don't-know option), which would probably be best. That would allow us to keep most of the optimizations, but it's probably a lot more work and more invasive. We have to pessimize something because we have a poorly-designed feature (i.e., one with an incomplete specification) that results in generating wrong code. What solution do you dislike least? How about the idea above of just zeroing the holes? -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com