This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Significantly reduce memory usage of genattrtab
- From: Richard Sandiford <richard dot sandiford at arm dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Bernd Schmidt <bschmidt at redhat dot com>
- Date: Tue, 15 Nov 2016 12:21:06 +0000
- Subject: Re: [PATCH] Significantly reduce memory usage of genattrtab
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR0701MB21624FB772F57D917B005BC9E4BF0@AM4PR0701MB2162.eurprd07.prod.outlook.com>
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