[PATCH] Shrink var-tracking.o text size

Richard Guenther rguenther@suse.de
Wed Jan 20 21:41:00 GMT 2010


On Wed, 20 Jan 2010, Jakub Jelinek wrote:

> On Wed, Jan 20, 2010 at 01:39:39PM +0100, Richard Guenther wrote:
> > Jakub, Alex - is there a more convenient place in var-tracking
> > to ignore INDIRECT_REF MEM_EXPR bases?
> 
> After some discussions with Alex on IRC, I think we should just have a
> compile time assertion instead of this costly dv_is_decl_p.  That will
> automatically allow INDIRECT_REF.
> 
> While it is possible (int) VALUE will in the future be != (int) IDENTIFIER_NODE
> that it currently equals, I think it isn't a change that happens every day
> (IDENTIFIER_NODE has been 1 even in 2.95 and VALUE has been moved
> intentionally right after UNKNOWN (== 0)), so if that compile time assertion
> ever fails, we can deal with it.  We don't need IDENTIFIER_NODE, just any
> tree code that really will never be seen by var-tracking code in
> RTL_EXPR/MEM_EXPR, parameters etc.
> 
> With the patch below, in stage3 build (still --enable-checking=yes)
> var-tracking.o shrunk from 65529 to 60914, i.e. 7%, and I'd expect compile
> time to improve as well.  Before the patch there were 198 calls to
> dv_is_decl_p, with the patch everything is inlined.  I remember from
> debugging the var-tracking is slow testcases that dv_is_decl_p showed really
> often in the backtraces, it is used inside of many inner loops. 
> 
> Ok for trunk if it passes bootstrap/regtest?
> 
> 2010-01-20  Jakub Jelinek  <jakub@redhat.com>
> 
> 	* var-tracking.c (check_value_val): Add a compile time assertion.
> 	(dv_is_decl_p): Simplify.
> 	(dv_as_decl, dv_as_value, dv_from_decl, dv_from_value): Only use
> 	gcc_assert if ENABLE_CHECKING.
> 
> --- gcc/var-tracking.c.jj	2010-01-14 23:39:00.000000000 +0100
> +++ gcc/var-tracking.c	2010-01-20 21:48:09.000000000 +0100
> @@ -109,6 +109,13 @@
>  #include "cselib.h"
>  #include "target.h"
>  
> +/* var-tracking.c assumes that tree code with the same value as VALUE rtx code
> +   has no chance to appear in REG_EXPR/MEM_EXPRs and isn't a decl.
> +   Currently the value is the same as IDENTIFIER_NODE, which has such
> +   a property.  If this compile time assertion ever fails, make sure that
> +   the new tree code that equals (int) VALUE has the same property.  */
> +extern char check_value_val[(int) VALUE == (int) IDENTIFIER_NODE ? 1 : -1];
> +
>  /* Type of micro operation.  */
>  enum micro_operation_type
>  {
> @@ -722,26 +729,7 @@ adjust_stack_reference (rtx mem, HOST_WI
>  static inline bool
>  dv_is_decl_p (decl_or_value dv)
>  {
> -  if (!dv)
> -    return true;
> -
> -  /* Make sure relevant codes don't overlap.  */
> -  switch ((int)TREE_CODE ((tree)dv))
> -    {
> -    case (int)VAR_DECL:
> -    case (int)PARM_DECL:
> -    case (int)RESULT_DECL:
> -    case (int)FUNCTION_DECL:
> -    case (int)DEBUG_EXPR_DECL:
> -    case (int)COMPONENT_REF:
> -      return true;
> -
> -    case (int)VALUE:
> -      return false;
> -
> -    default:
> -      gcc_unreachable ();
> -    }
> +  return !dv || (int) TREE_CODE ((tree) dv) != (int) VALUE;


Note that this is still an alias violation if *dv is a RTX.
You should access the codes via a pointer to short
(ugh, it's both a bitfield ... can we make it a short instead?)

Thus, *(short *)&TREE_CODE ((tree) dv) with both ENUM_BITFIELDs
turned into a short.

Well, or maybe only once we start miscompiling var-tracking ;)

Richard.



More information about the Gcc-patches mailing list