From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2162 invoked by alias); 18 Mar 2004 08:19:56 -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 2140 invoked from network); 18 Mar 2004 08:19:55 -0000 Received: from unknown (HELO mail.libertysurf.net) (213.36.80.91) by sources.redhat.com with SMTP; 18 Mar 2004 08:19:55 -0000 Received: from localhost.localdomain (212.129.22.75) by mail.libertysurf.net (6.5.036) id 403C4572026075E4; Thu, 18 Mar 2004 09:19:50 +0100 From: Eric Botcazou To: Mark Mitchell Subject: Re: GCC Status Report (2004-03-09) Date: Thu, 18 Mar 2004 08:25:00 -0000 User-Agent: KMail/1.4.3 Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <200403171156.56151.ebotcazou@libertysurf.fr> <405874AD.2010709@codesourcery.com> In-Reply-To: <405874AD.2010709@codesourcery.com> MIME-Version: 1.0 Message-Id: <200403180924.19533.ebotcazou@libertysurf.fr> Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_VDJRU74D2KKH0RBV88CC" X-SW-Source: 2004-03/txt/msg01019.txt.bz2 --------------Boundary-00=_VDJRU74D2KKH0RBV88CC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-length: 1021 > (1) Try my scheduling barrier idea, where we introduce a volatile asm > equivalent between the clearing and the normal assignment. I know this > is potentially pessimizing, but in practice the pessimization will > probably be slight. > > (2) In the unsafe case, implement the C99 rule by explicitly clearing > each individual field. In other words, iterate through the fields, > clearing all of the fields that do not have an explicit CONSTRUCTOR_ELT. > > I think (1) will probably be less pessimizing that (2). Are you willing > to give that a try? The attached patch fixes PR opt/13424 (both on PA and UltraSPARC) and doesn't do any harm to the testcase on x86. OK for mainline and 3.4 branch after a complete testing cycle on x86? 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. -- Eric Botcazou --------------Boundary-00=_VDJRU74D2KKH0RBV88CC Content-Type: text/x-diff; charset="iso-8859-1"; name="pr13424-2.diff" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="pr13424-2.diff" Content-length: 1116 Index: expr.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/expr.c,v retrieving revision 1.615.4.9 diff -u -p -r1.615.4.9 expr.c --- expr.c 13 Mar 2004 18:26:23 -0000 1.615.4.9 +++ expr.c 17 Mar 2004 17:56:20 -0000 @@ -4560,6 +4560,18 @@ store_constructor (tree exp, rtx target, clear_storage (xtarget, GEN_INT (size)); cleared = 1; + + /* ??? Emit a blockage to prevent the scheduler from swapping the + memory write issued just above and the memory write that may be + issued below to initialize each field. This is needed for a + read-write field because the former write may carry the /u + flag and not the latter, so they will not conflict. Note that + the clearing cannot be simply disabled in the unsafe cases + because the C front-end relies on it to implement the semantics + of constructors for automatic objects. + However, not all machine descriptions define a blockage insn, + so emit an ASM_INPUT to act as one.  */ + emit_insn (gen_rtx_ASM_INPUT (VOIDmode, "")); } if (! cleared) --------------Boundary-00=_VDJRU74D2KKH0RBV88CC--