From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6413 invoked by alias); 20 Apr 2011 08:51:38 -0000 Received: (qmail 6403 invoked by uid 22791); 20 Apr 2011 08:51:37 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 20 Apr 2011 08:51:23 +0000 Received: by wwf26 with SMTP id 26so565787wwf.8 for ; Wed, 20 Apr 2011 01:51:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.139.149 with SMTP id e21mr7149834wbu.147.1303289481699; Wed, 20 Apr 2011 01:51:21 -0700 (PDT) Received: by 10.227.0.140 with HTTP; Wed, 20 Apr 2011 01:51:21 -0700 (PDT) In-Reply-To: <20110419220053.GK23480@codesourcery.com> References: <20110404160038.GC23480@codesourcery.com> <20110419220053.GK23480@codesourcery.com> Date: Wed, 20 Apr 2011 09:18:00 -0000 Message-ID: Subject: Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL From: Richard Guenther To: Nathan Froyd Cc: Michael Matz , Steven Bosscher , GCC Patches Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg01621.txt.bz2 On Wed, Apr 20, 2011 at 12:00 AM, Nathan Froyd w= rote: > On Tue, Apr 05, 2011 at 05:55:33PM +0200, Michael Matz wrote: >> I have a preference in having just one DECL_RTL field for conceptual >> reasons: >> >> Most DECLs are actually objects (there are some prominent exceptions, but >> those always would be better described with something like NAMED_ENTITY, >> if we had something like that, namespaces and translation_unit would >> qualify). =A0All these have a RTL representation, so one field for them >> seems appropriate. =A0That some of those don't have a size (either becau= se >> size makes no sense or is always available via type size) hints towards a >> problem in the inheritance. =A0I would think it should look like so: >> >> decl_common {} =A0# no size, no rtl, no align, no pt_uid >> decl_with_rtl : decl_common { >> =A0 # add rtl, align, pt_uid >> } >> decl_with_size : decl_with_rtl { >> =A0 # add size, size_unit >> } >> >> Then decl_common can still be used for >> imported_decl/namespace/translation_unit; objects >> are at least decl_with_rtl, and some objects will be decl_with_size. > > I had occasion to try this today; this inheritance structure doesn't > work. =A0The truncated inheritance tree looks like: > > * decl_common > =A0* field_decl > =A0* const_decl > =A0* decl_with_rtl > =A0 =A0* label_decl > =A0 =A0* result_decl > =A0 =A0* parm_decl > =A0 =A0* decl_with_vis... > > In particular, FIELD_DECLs have a size, but they have no RTL associated > with them. =A0And LABEL_DECLs have RTL, but no size. =A0So if you went wi= th > the above, FIELD_DECLs would grow by one (useless) word. =A0And the > reverse is the situation we have today, where CONST_DECLs and > LABEL_DECLs (at least) have a pointless DECL_SIZE. =A0Ideally, we could > fix things like FUNCTION_DECLs having a size, too... > > And I didn't check the C++ FE to see if there are problematic cases > there, either. > > What do you think is the next step? =A0To address this issue, we could > just give LABEL_DECL its own rtx field as in the original patch, and > that would resolve that. =A0But maybe we should go further, say by making > DECL_SIZE{,_UNIT} and/or DECL_RTL into actual (out-of-line function) > accessors; these accessors can then access structure-specific bits of > data. =A0Then we don't have to worry about the inheritance structure, and > maybe could adopt alternate storage schemes for different DECLs, such as > the off-to-the-side table that Steven suggested. Another option is to change nothing ;) Conceptually I'd say not storing DECL_RTL in the decls themselves but on the side would make sense, at least from a stylish view. I'm not sure it'll work out very well though in terms of cost & benefit. What we could do is, if we ever can dispose of DECL/TYPE_LANG_SPECIFIC after lowering to gimple, overload that field with a DECL/TYPE_RTL_SPECIFIC field ... Richard. > -Nathan >