This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Significantly reduce memory usage of genattrtab


Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> Hi!
>
> The genattrtab build-tool uses way too much memory in general.
> I think there is no other build step that uses more memory.
>
> On the currently trunk it takes around 700MB to build the
> ARM latency tab files.  I debugged that yesterday
> and found that this can be reduced to 8MB (!).  Yes, really.
>
> So the attached patch does try really hard to hash and re-use
> all ever created rtx objects.
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu and ARM.
> Is it OK for trunk?

Just to check: does this produce the same output as before?
And did you notice any difference in the time genattrtab
takes to run?

> Index: gcc/genattrtab.c
> ===================================================================
> --- gcc/genattrtab.c	(revision 242335)
> +++ gcc/genattrtab.c	(working copy)
> @@ -395,14 +395,6 @@ attr_rtx_1 (enum rtx_code code, va_list p)
>      {
>        rtx arg0 = va_arg (p, rtx);
>  
> -      /* A permanent object cannot point to impermanent ones.  */
> -      if (! ATTR_PERMANENT_P (arg0))
> -	{
> -	  rt_val = rtx_alloc (code);
> -	  XEXP (rt_val, 0) = arg0;
> -	  return rt_val;
> -	}
> -
>        hashcode = ((HOST_WIDE_INT) code + RTL_HASH (arg0));
>        for (h = attr_hash_table[hashcode % RTL_HASH_SIZE]; h; h = h->next)
>  	if (h->hashcode == hashcode
> @@ -425,15 +417,6 @@ attr_rtx_1 (enum rtx_code code, va_list p)
>        rtx arg0 = va_arg (p, rtx);
>        rtx arg1 = va_arg (p, rtx);
>  
> -      /* A permanent object cannot point to impermanent ones.  */
> -      if (! ATTR_PERMANENT_P (arg0) || ! ATTR_PERMANENT_P (arg1))
> -	{
> -	  rt_val = rtx_alloc (code);
> -	  XEXP (rt_val, 0) = arg0;
> -	  XEXP (rt_val, 1) = arg1;
> -	  return rt_val;
> -	}
> -
>        hashcode = ((HOST_WIDE_INT) code + RTL_HASH (arg0) + RTL_HASH (arg1));
>        for (h = attr_hash_table[hashcode % RTL_HASH_SIZE]; h; h = h->next)
>  	if (h->hashcode == hashcode

ATTR_PERMANENT_P is supposed to guarantee that no other rtx like it exists,
so that x != y when x or y is "permanent" implies that the attributes
must be different.  This lets attr_equal_p avoid a recursive walk:

static int
attr_equal_p (rtx x, rtx y)
{
  return (x == y || (! (ATTR_PERMANENT_P (x) && ATTR_PERMANENT_P (y))
		     && rtx_equal_p (x, y)));
}

Does the patch still guarantee that?

Thanks,
Richard


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]