From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19422 invoked by alias); 25 Nov 2001 00:57:29 -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 19401 invoked from network); 25 Nov 2001 00:57:28 -0000 Received: from unknown (HELO taltos.codesourcery.com) (66.92.14.122) by sourceware.cygnus.com with SMTP; 25 Nov 2001 00:57:28 -0000 Received: from zack by taltos.codesourcery.com with local (Exim 3.32 #1 (Debian)) id 167nbq-0000R3-00; Sat, 24 Nov 2001 16:57:26 -0800 Date: Thu, 15 Nov 2001 04:55:00 -0000 To: Neil Booth Cc: Gabriel Dos Reis , Mark Mitchell , "gcc@gcc.gnu.org" Subject: Re: ICE in change_address at emit_rtl.c Message-ID: <20011124165726.C1538@codesourcery.com> References: <72730000.1006640472@warlock.codesourcery.com> <20011124230256.B4815@daikokuya.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011124230256.B4815@daikokuya.demon.co.uk> User-Agent: Mutt/1.3.23i From: Zack Weinberg X-SW-Source: 2001-11/txt/msg00669.txt.bz2 On Sat, Nov 24, 2001 at 11:02:56PM +0000, Neil Booth wrote: > > I've often wondered whether we might do better type-wise to actually > use separate types, and refer to them as separate types, rather than > having every function take an effectively typeless "tree" as input. Once again you seem to be thinking along parallel lines to me - I was coming at it from the tack of trying to cut down memory consumption, but it's the same problem. I see definite benefits from using independent structures for all constants, identifiers, and possibly types. I don't think it makes sense to go as far as separating all the current members of tree_union. It is genuinely useful to be able to treat the operands of any expression with the same logic, which argues for e.g. leaving declarations as part of the tree union (but then, it does the same for constants...) > Am I right in thinking that the only common thing that every "tree" > really needs to have is the chain element and tree code? Less! An identifier has no use for the chain, or for most of the flags. There are some counter-pressures against shrinking trees too far. One is the real danger of running out of tree_code values. That's an 8-bit field and C++ has more than 200 tree codes. Another is the demand for flag bits. And there are very few trees that don't need at least a cons-cell worth of pointers; that's eight bytes (on a 32-bit machine) right there. (Oh, can we please #if 0 out the aux field in tree_common? The only code that's using it is on the ast-optimizer-branch which will not be merged in 3.1 - all it's doing is wasting memory.) zw