Re: [PATCH] Make extra_order_size_table effective on targets with MAX_ALIGNMENT > 4

[Richard Guenther <rguenther at suse dot de>]

On Wed, 21 Jun 2006, Richard Guenther wrote:

> 
> On x86_64 (and other targets with MAX_ALIGNMENT > 4), the 
> extra_order_size_table is ineffective, especially for small sizes, due
> to rounding to MAX_ALIGNMENT.  We can avoid that by ensuring the
> allocation bin from a size_lookup query honours the appearant alignment
> requirement from the allocation size (which has to follow
> sizeof (T) % alignof (T) == 0).
> 
> This cut's down (tramp3d, 8GB ram, -O, x86_64) GC garbage (10%) and overhead
> (350%) significantly:
> 
> from
> 
> source location                                     Garbage            Freed             Leak         Overhead            Times
> Total                                            2419980557        381016068        189677707        161937348         34896716
> 
> to
> 
> Total                                            2187873005        377805948        191847627         46120732         34868419
> 
> Bootstrapped and tested on x86_64-unknown-linux and ia64-unknown-linux (with
> unaligned traps turned on).
> 
> Ok for mainline?

Unfortunately this version regresses in terms of max. virtual memory use
on that machine for tramp3d due to the fact that bin sizes 112, 192 and 
224 are no longer in extra_order_size_table (these are the rounded-up
values).  Looking for suitable structures to add to the table to get
those back I find

rguenther@mozart:/abuild/rguenther/obj-gcc-g/gcc> readelf -wi cc1 | grep 
-C2 'DW_AT_byte_size   : 112' | grep DW_AT_name | sort | uniq
     DW_AT_name        : (indirect string, offset: 0x2f0a9): htab
     DW_AT_name        : arg
     DW_AT_name        : conflict_graph_def
     DW_AT_name        : htab
     DW_AT_name        : tree_binfo
     DW_AT_name        : work_stuff
rguenther@mozart:/abuild/rguenther/obj-gcc-g/gcc> readelf -wi cc1 | grep 
-C2 'DW_AT_byte_size   : 192' | grep DW_AT_name | sort | uniq
rguenther@mozart:/abuild/rguenther/obj-gcc-g/gcc> readelf -wi cc1 | grep 
-C2 'DW_AT_byte_size   : 224' | grep DW_AT_name | sort | uniq
     DW_AT_name        : (indirect string, offset: 0x12a01): tree_node
     DW_AT_name        : (indirect string, offset: 0x1d614): cfg_hooks
     DW_AT_name        : (indirect string, offset: 0x2e40d): _cpp_file
     DW_AT_name        : cfg_hooks
     DW_AT_name        : lang_tree_node
     DW_AT_name        : tree_function_decl
     DW_AT_name        : tree_node

and chose struct tree_function_decl and struct tree_binfo (ignoring
the size 192, which is after verification not causing the regression).

Ok with adding those two entries to the table?  (for 32bit it adds
struct tree_binfo, 60 bytes, which was not there before, 
tree_function_decl size (112) matches sizeof (struct tree_phi_node) + 
sizeof (struct phi_arg_d) * 3.

Thanks again,
Richard.

> 2006-06-21  Richard Guenther  <rguenther@suse.de>
> 
> 	* ggc-page.c (init_ggc): Do not round up the extra_order_size_table
> 	sizes to MAX_ALIGNMENT.  Fix the size_lookup table to honour
> 	alignment requests instead.  Add verification code.