From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27504 invoked by alias); 19 Mar 2004 18:41:00 -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 27491 invoked from network); 19 Mar 2004 18:40:58 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sources.redhat.com with SMTP; 19 Mar 2004 18:40:58 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA26648; Fri, 19 Mar 04 13:44:20 EST Date: Fri, 19 Mar 2004 20:08:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10403191844.AA26648@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/msg01161.txt.bz2 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. Well I can tell you the *purpose*, but if you want the *definition*, that's something else entirely. The original idea was to separate objects that we knew could not be modified by stores, like constant pool objects. Then, at some later point, it was realized that we could also optimize by allowing a *single* store to "constant" object to initialize it, but things started rapidly going downhill once we started to take more and more advantage of that property.