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

[Kenneth Zadeck <zadeck at naturalbridge dot 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
>
>
>