This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Antwort: Re: Antwort: patch to shrink the size of df_refs.


Kenneth Zadeck <zadeck@naturalbridge.com> schrieb am 25.09.2008 13:53:55:

> Markus Milleder wrote:
> > gcc-patches-owner@gcc.gnu.org schrieb am 25.09.2008 02:10:12:
> >
> >> This patch makes a modest reduction in the size of df_refs.   It does
> >>
> > Is this worth the complication ?
> >
> > To my untrained eye, the only savings is putting the bb pointer
> > (in df_artificial_ref) at the same place as the rtx pointer
> > (in df_regular_ref and df_extract_ref).
> >
> >
> no, there are also no loc pointers in many of the regular refs so they
> use the base_ref version which saves another pointer.

... which has no effect on the total size of the union, unless I totally
misunderstand how unions work.

I.e. sizeof(df_ref_d) == max( sizeof(any of the possibilities) ), which
by my count is struct df_extract_ref.

Compare the suggested
> >> +union df_ref_d
> >> +{
> >> +  struct df_base_ref base;
> >> +  struct df_regular_ref regular_ref;
> >> +  struct df_artificial_ref artificial_ref;
> >> +  struct df_extract_ref extract_ref;
> >> +};
to a hypothetical
struct df_ref_d {
    struct df_base_ref base; // <-- plain df_base_ref up to here :-)
    rtx *loc;      // <-- df_regular_ref up to here
                   // bb would be here in the union
    int width;
    int offset;
    enum machine_mode mode; // <-- df_extract_ref up to here, size of the union
    basic_block bb;   // addition from df_artificial_ref
};
that just contains all the fields of the possible union cases.

Am I overlooking something ?

Understanding that there are several subtypes, and which are used where,
as well as reordering/commenting the fields by subtype, are IMO worthy
goals. But I think the complication of handling the subtyping may
outweigh the benefit of the memory savings (52 vs 56 bytes for 32bit,
96 vs 102 for 64bit by my count, with the change to id and regnum).

      Markus Milleder



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]