From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2227 invoked by alias); 18 Mar 2004 23:29: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 2044 invoked from network); 18 Mar 2004 23:28:57 -0000 Received: from unknown (HELO mail.libertysurf.net) (213.36.80.91) by sources.redhat.com with SMTP; 18 Mar 2004 23:28:57 -0000 Received: from localhost.localdomain (212.129.22.31) by mail.libertysurf.net (6.5.036) id 4059C985000B8E31; Fri, 19 Mar 2004 00:28:56 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Eric Botcazou To: Mark Mitchell Subject: Re: GCC Status Report (2004-03-09) Date: Thu, 18 Mar 2004 23:36:00 -0000 User-Agent: KMail/1.4.3 Cc: gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org References: <200403091809.i29I9P04020607@sirius.codesourcery.com> <200403181927.00513.ebotcazou@libertysurf.fr> <4059EE8A.4060407@codesourcery.com> In-Reply-To: <4059EE8A.4060407@codesourcery.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200403190031.22113.ebotcazou@libertysurf.fr> X-SW-Source: 2004-03/txt/msg01092.txt.bz2 > 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. This can probably be awful in certain cases too (mix const/non-const, bitfields, packed fields, ...). And this would defeat the clrstr patterns, on x86 for example. > We could also disable the use of RTX_UNCHANGING_P in alias.c. Could this be done somewhat selectively? > 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. Unfortunately, yes, this appears to be unavoidable. > What solution do you dislike least? Nice formulation :-) Richard (rth) even proposed to disable entirely RTX_UNCHANGING_P in 3.4/3.5. I personally think the 3.3.x code is cleaner (albeit probably not 100% safe). > How about the idea above of just zeroing the holes? If you're fine with the blockage approach... -- Eric Botcazou