[PATCH] Decrease integer-share-limit

[Richard Guenther <rguenther@suse.de>]

This decreases the integer-share-limit to make sure the TREE_VEC we
allocate for the small cached integers has a reasonable size for
our GC memory allocator.  With the current value (256) and a reduced 
testcase from PR54146 we see

tree.c:1224 (build_int_cst_wide)                         40: 0.0%          
0: 0.0%   35443680: 8.7%   11635920:39.0%       9305

thus 39% overhead (oops, that TREE_VEC has size 2080).  Reducing
this to 251 yields

tree.c:1224 (build_int_cst_wide)                         40: 0.0%          
0: 0.0%   11698864: 3.0%      33696: 0.2%       9154

which is much nicer (size 2048 for signed ints, 1020 bytes on
32bit hosts if I counted correctly).

I'm queueing this for a bootstrap & regtest run.

Richard.

2012-08-16  Richard Guenther  <rguenther@suse.de>

	* params.def (integer-share-limit): Decrease from 256 to 251,
	add rationale.

Index: gcc/params.def
===================================================================
*** gcc/params.def	(revision 190442)
--- gcc/params.def	(working copy)
*************** DEFPARAM(PARAM_MAX_LAST_VALUE_RTL,
*** 638,648 ****
  
  /* INTEGER_CST nodes are shared for values [{-1,0} .. N) for
     {signed,unsigned} integral types.  This determines N.
!    Experimentation shows 256 to be a good value.  */
  DEFPARAM (PARAM_INTEGER_SHARE_LIMIT,
  	  "integer-share-limit",
  	  "The upper bound for sharing integer constants",
! 	  256, 2, 2)
  
  DEFPARAM (PARAM_SSP_BUFFER_SIZE,
  	  "ssp-buffer-size",
--- 638,649 ----
  
  /* INTEGER_CST nodes are shared for values [{-1,0} .. N) for
     {signed,unsigned} integral types.  This determines N.
!    Experimentation shows 251 to be a good value that generates the
!    least amount of garbage for allocating the TREE_VEC storage.  */
  DEFPARAM (PARAM_INTEGER_SHARE_LIMIT,
  	  "integer-share-limit",
  	  "The upper bound for sharing integer constants",
! 	  251, 2, 2)
  
  DEFPARAM (PARAM_SSP_BUFFER_SIZE,
  	  "ssp-buffer-size",