[PATCH] Re-visit GC extra_order_size_table, decrease MAX_ALIGNMENT

Richard Guenther rguenther@suse.de
Sun Oct 18 16:51:00 GMT 2009


Following http://gcc.gnu.org/ml/gcc/2009-10/msg00386.html this
decreases MAX_ALIGNMENT on x86_64 by not considering floating point
types for alignment of GC allocations (and alloc-pools).  The
reasoning that this should be generally safe is that using floating-point
will cause code generation differences dependent on the host.  And
indeed, grepping doesn't show any use of FP types in GC allocated
structures.

The patch also avoids the usual chasing of structure layout changes
between releases and adds a set of standard extra GC page orders
covering all small multiples of MAX_ALIGNMENT.  It also adds a few
structures based on GC overhead measurement I did on SPEC 2006
with LTO on x86_64 and on SPEC 2000 with LTO on i686.

Bootstrapped and tested on x86_64-unknown-linux-gnu.  I consider
applying this after giving people the chance to respond to the
cited thread.

Richard.

2009-10-18  Richard Guenther  <rguenther@suse.de>

	* ggc-page.c: Include cfgloop.h.
	(struct max_alignment): Drop long double, add void *.
	(extra_order_size_table): Add low non-power-of-two multiples
	of MAX_ALIGNMENT.  Drop small type-based entries, add
	tree_type, cgraph_node and loop.
	* alloc-pool.c (struct allocation_object_def): Drop long double
	aligning element.


Index: gcc/ggc-page.c
===================================================================
*** gcc/ggc-page.c	(revision 152966)
--- gcc/ggc-page.c	(working copy)
*************** along with GCC; see the file COPYING3.  
*** 31,36 ****
--- 31,37 ----
  #include "timevar.h"
  #include "params.h"
  #include "tree-flow.h"
+ #include "cfgloop.h"
  #include "plugin.h"
  
  /* Prefer MAP_ANON(YMOUS) to /dev/zero, since we don't need to keep a
*************** along with GCC; see the file COPYING3.  
*** 157,162 ****
--- 158,181 ----
  #define OFFSET_TO_BIT(OFFSET, ORDER) \
    (((OFFSET) * DIV_MULT (ORDER)) >> DIV_SHIFT (ORDER))
  
+ /* We use this structure to determine the alignment required for
+    allocations.  For power-of-two sized allocations, that's not a
+    problem, but it does matter for odd-sized allocations.
+    We do not care about alignment for floating-point types.  */
+ 
+ struct max_alignment {
+   char c;
+   union {
+     HOST_WIDEST_INT i;
+     void *p;
+   } u;
+ };
+ 
+ /* The biggest alignment required.  */
+ 
+ #define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
+ 
+ 
  /* The number of extra orders, not corresponding to power-of-two sized
     objects.  */
  
*************** along with GCC; see the file COPYING3.  
*** 173,214 ****
     thing you need to do to add a new special allocation size.  */
  
  static const size_t extra_order_size_table[] = {
!   sizeof (struct var_ann_d),
    sizeof (struct tree_decl_non_common),
    sizeof (struct tree_field_decl),
    sizeof (struct tree_parm_decl),
    sizeof (struct tree_var_decl),
!   sizeof (struct tree_list),
!   sizeof (struct tree_ssa_name),
    sizeof (struct function),
    sizeof (struct basic_block_def),
!   sizeof (bitmap_element),
!   sizeof (bitmap_head),
!   TREE_EXP_SIZE (2),
!   RTL_SIZE (2),			/* MEM, PLUS, etc.  */
!   RTL_SIZE (9),			/* INSN */
  };
  
  /* The total number of orders.  */
  
  #define NUM_ORDERS (HOST_BITS_PER_PTR + NUM_EXTRA_ORDERS)
  
- /* We use this structure to determine the alignment required for
-    allocations.  For power-of-two sized allocations, that's not a
-    problem, but it does matter for odd-sized allocations.  */
- 
- struct max_alignment {
-   char c;
-   union {
-     HOST_WIDEST_INT i;
-     long double d;
-   } u;
- };
- 
- /* The biggest alignment required.  */
- 
- #define MAX_ALIGNMENT (offsetof (struct max_alignment, u))
- 
  /* Compute the smallest nonnegative number which when added to X gives
     a multiple of F.  */
  
--- 192,226 ----
     thing you need to do to add a new special allocation size.  */
  
  static const size_t extra_order_size_table[] = {
!   /* Extra orders for small non-power-of-two multiples of MAX_ALIGNMENT.
!      There are a lot of structures with these sizes and explicitly
!      listing them risks orders being dropped because they changed size.  */
!   MAX_ALIGNMENT * 3,
!   MAX_ALIGNMENT * 5,
!   MAX_ALIGNMENT * 6,
!   MAX_ALIGNMENT * 7,
!   MAX_ALIGNMENT * 9,
!   MAX_ALIGNMENT * 10,
!   MAX_ALIGNMENT * 11,
!   MAX_ALIGNMENT * 12,
!   MAX_ALIGNMENT * 13,
!   MAX_ALIGNMENT * 14,
!   MAX_ALIGNMENT * 15,
    sizeof (struct tree_decl_non_common),
    sizeof (struct tree_field_decl),
    sizeof (struct tree_parm_decl),
    sizeof (struct tree_var_decl),
!   sizeof (struct tree_type),
    sizeof (struct function),
    sizeof (struct basic_block_def),
!   sizeof (struct cgraph_node),
!   sizeof (struct loop),
  };
  
  /* The total number of orders.  */
  
  #define NUM_ORDERS (HOST_BITS_PER_PTR + NUM_EXTRA_ORDERS)
  
  /* Compute the smallest nonnegative number which when added to X gives
     a multiple of F.  */
  
Index: gcc/alloc-pool.c
===================================================================
*** gcc/alloc-pool.c	(revision 152966)
--- gcc/alloc-pool.c	(working copy)
*************** typedef struct allocation_object_def
*** 41,50 ****
  
        /* Because we want any type of data to be well aligned after the ID,
  	 the following elements are here.  They are never accessed so
! 	 the allocated object may be even smaller than this structure.  */
        char *align_p;
        HOST_WIDEST_INT align_i;
-       long double align_ld;
      } u;
  } allocation_object;
  
--- 41,50 ----
  
        /* Because we want any type of data to be well aligned after the ID,
  	 the following elements are here.  They are never accessed so
! 	 the allocated object may be even smaller than this structure.
! 	 We do not care about alignment for floating-point types.  */
        char *align_p;
        HOST_WIDEST_INT align_i;
      } u;
  } allocation_object;
  



More information about the Gcc-patches mailing list