This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 6/9] Add --param tunables for the initial size of the type merging hash tables
- From: Andi Kleen <ak at linux dot intel dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, gcc-patches at gcc dot gnu dot org, hubicka at ucw dot cz
- Date: Mon, 22 Apr 2013 08:44:44 -0700
- Subject: Re: [PATCH 6/9] Add --param tunables for the initial size of the type merging hash tables
- References: <1366407117-18462-1-git-send-email-andi at firstfloor dot org> <1366407117-18462-7-git-send-email-andi at firstfloor dot org> <CAFiYyc3qE6E3f4sdM+Xa6gck0_8-6-hOSWBS0NawncijLb8WTg at mail dot gmail dot com>
On Mon, Apr 22, 2013 at 01:49:39PM +0200, Richard Biener wrote:
> On Fri, Apr 19, 2013 at 11:31 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > From: Andi Kleen <ak@linux.intel.com>
> >
> > WPA can spend a lot of time just resizing the type merging hash tables.
> > This adds experimental --params to size them large initially. On my large
> > LTO build I get a 1.1% improvement in build time from presizing the hash
> > tables to a large enough value.
>
> With what values? Certainly we will have at least as many hashes
For the test I used just the final values from -flto-report from a previous
run. I know it's cheating. But it's reasonable to just always use a
large table, unless someone comes up with a nice way to pre estimate.
> as types, so increasing the hash cache sizes to the size of the types
> (thus use the same --param) would be obvious. Likewise there will
iirc the caches were usually smaller than the types from lto-report. Perhaps
they have less collisions.
-Andi