On Wed, Apr 20, 2011 at 12:00 AM, Nathan Froyd <froy...@codesourcery.com> wrote:
> 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). All these have a RTL representation, so one field for them
>> seems appropriate. That some of those don't have a size (either because
>> size makes no sense or is always available via type size) hints towards a
>> problem in the inheritance. I would think it should look like so:
>>
>> decl_common {} # no size, no rtl, no align, no pt_uid
>> decl_with_rtl : decl_common {
>> # add rtl, align, pt_uid
>> }
>> decl_with_size : decl_with_rtl {
>> # 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. 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. So if you went with
> the above, FIELD_DECLs would grow by one (useless) word. And the
> reverse is the situation we have today, where CONST_DECLs and
> LABEL_DECLs (at least) have a pointless DECL_SIZE. Ideally, 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? To address this issue, we could
> just give LABEL_DECL its own rtx field as in the original patch, and
> that would resolve that. But 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. Then 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
>
