From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17519 invoked by alias); 19 Mar 2004 08:14: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 17504 invoked from network); 19 Mar 2004 08:14:34 -0000 Received: from unknown (HELO mx2.redhat.com) (66.187.237.31) by sources.redhat.com with SMTP; 19 Mar 2004 08:14:34 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i2J7mhA08282; Fri, 19 Mar 2004 02:48:43 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2J8EWj11987; Fri, 19 Mar 2004 03:14:32 -0500 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i2J8EI1n019463; Fri, 19 Mar 2004 03:14:18 -0500 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.12.10/8.12.10/Submit) id i2J8EI72019461; Fri, 19 Mar 2004 03:14:18 -0500 Date: Fri, 19 Mar 2004 12:18:00 -0000 From: Jakub Jelinek To: Richard Kenner Cc: ebotcazou@libertysurf.fr, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: GCC Status Report (2004-03-09) Message-ID: <20040319081418.GJ31589@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <10403190126.AA20411@vlsi1.ultra.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10403190126.AA20411@vlsi1.ultra.nyu.edu> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-03/txt/msg01116.txt.bz2 On Thu, Mar 18, 2004 at 08:26:30PM -0500, Richard Kenner wrote: > 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. That would be certainly safest and the UNCHANGING would really mean unchanging. But I hope we could at least extend it to objects which are *never* stored into in current function (see if the object is initialized in the function currently expanded into RTL, if not, use RTX_UNCHANGING_P for it as well, otherwise perhaps use some other bit or alias set). Jakub