This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Antwort: Re: Antwort: patch to shrink the size of df_refs.
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Markus Milleder <markus dot milleder at generali dot at>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "Hubicha, Jan" <jh at suse dot cz>, Seongbae Park <spark at google dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>
- Date: Thu, 25 Sep 2008 11:39:17 -0400
- Subject: Re: Antwort: Re: Antwort: patch to shrink the size of df_refs.
- References: <OF8D29AA96.777F3112-ONC12574CF.004B845F-C12574CF.004D28B3@AT.TOP.COM>
Markus Milleder wrote:
> 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.
>
>
no, you have misunderstood. If you look in the code in df-scan.c ,
you will see that there is a different alloc pool for each of the 4
variants, each with an element size based on the size of the variant,
not the size of the total union.
@@ -344,12 +349,18 @@ df_scan_alloc (bitmap all_blocks ATTRIBU
df_scan->problem_data = problem_data;
df_scan->computed = true;
- problem_data->ref_pool
- = create_alloc_pool ("df_scan_ref pool",
- sizeof (struct df_ref), block_size);
+ problem_data->ref_base_pool
+ = create_alloc_pool ("df_scan_ref base pool",
+ sizeof (struct df_base_ref), block_size);
+ problem_data->ref_artificial_pool
+ = create_alloc_pool ("df_scan_ref artificial pool",
+ sizeof (struct df_artificial_ref), block_size);
+ problem_data->ref_regular_pool
+ = create_alloc_pool ("df_scan_ref regular pool",
+ sizeof (struct df_regular_ref), block_size);
problem_data->ref_extract_pool
= create_alloc_pool ("df_scan_ref extract pool",
- sizeof (struct df_ref_extract), block_size);
+ sizeof (struct df_extract_ref), block_size);
problem_data->insn_pool
= create_alloc_pool ("df_scan_insn pool",
sizeof (struct df_insn_info), block_size);
> 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
>
>
>