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.
-Nathan
