From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21149 invoked by alias); 21 Apr 2011 15:54:48 -0000 Received: (qmail 21138 invoked by uid 22791); 21 Apr 2011 15:54:44 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 21 Apr 2011 15:54:30 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 8938694109; Thu, 21 Apr 2011 17:54:29 +0200 (CEST) Date: Thu, 21 Apr 2011 16:34:00 -0000 From: Michael Matz To: Nathan Froyd Cc: Richard Guenther , Steven Bosscher , GCC Patches Subject: Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL In-Reply-To: Message-ID: References: <20110404160038.GC23480@codesourcery.com> <20110419220053.GK23480@codesourcery.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="168427776-915629371-1303400082=:1989" Content-ID: X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01794.txt.bz2 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --168427776-915629371-1303400082=:1989 Content-Type: TEXT/PLAIN; CHARSET=utf-8 Content-Transfer-Encoding: 8BIT Content-ID: Content-length: 1647 Hi, On Wed, 20 Apr 2011, Richard Guenther wrote: > > I had occasion to try this today; this inheritance structure doesn't > > work.  The truncated inheritance tree looks like: > > > > * decl_common > >  * field_decl > >  * const_decl > >  * decl_with_rtl > >    * label_decl > >    * result_decl > >    * parm_decl > >    * decl_with_vis... > > > > In particular, FIELD_DECLs have a size, but they have no RTL associated > > with them.  And LABEL_DECLs have RTL, but no size. Blaeh. So far about nice clean ideas :) One hacky idea: change my proposal to this: decl_common {}  # no size, no rtl, no align, no pt_uid decl_with_rtl_or_size : decl_common {   # add align, pt_uid union { rtx rtl; tree size; } u; } decl_with_size : decl_with_rtl_or_size {   # add size, size_unit } Use the rtl_or_size struct primarily for the current _with_rtl things that don't naturally have a size, but use it also for FIELD_DECLs via the union. Alternatively I could also envision making a new tree_ struct for just field_decls, that would contain the size and other fields that currently are in decl_common just for fields (in particular the off_align) member. The various accessors like DECL_SIZE would then need to dispatch based on tree code. Also doesn't sound terribly sexy. FWIW I'm usually against on the side mappings A->B if most As will most of the time be associated with a B. A size _is_ associated with the entity always (for entities where it makes sense to talk about sizes), so that's exactly where I would find on the side tables strange. For DECL_RTL it's less clear. Ciao, Michael. --168427776-915629371-1303400082=:1989--