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