From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9620 invoked by alias); 19 Mar 2004 01:23:08 -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 9498 invoked from network); 19 Mar 2004 01:23:07 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 19 Mar 2004 01:23:07 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA20411; Thu, 18 Mar 04 20:26:30 EST Date: Fri, 19 Mar 2004 06:34:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10403190126.AA20411@vlsi1.ultra.nyu.edu> To: ebotcazou@libertysurf.fr Subject: Re: GCC Status Report (2004-03-09) Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org X-SW-Source: 2004-03/txt/msg01104.txt.bz2 > Can't we at least detect the case where either the whole aggregate > is const or all its fields are const? Then we don't need any blockage. So we endorse the double /u liberality? I don't. As I said in more private email, my feeling in the /u case where you have a partial aggregate is to do the stores into a temporary and move it into the /u. Yes, that's less efficient and in many ways more than undoes the advantage of /u, but partial aggregates are rare. I think that's cleaner than blockage stuff. I don't know what to think about /u overall. It's becoming more and more clear that it's the source of a lot of trouble and probably is becoming less and less useful with aliasing code around anyway. I'd be in favor of trying the experiment of only using it on data that's *never* explicitly stored (like constant-pool or items with static initializers). So we disallow stores to /u.