This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL
On Wed, Apr 20, 2011 at 12:00 AM, Nathan Froyd <froydnj@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
>