This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Take branch misprediction effects into account when RTL loop unrolling (issue6099055)
- From: Andi Kleen <andi at firstfloor dot org>
- To: tejohnson at google dot com (Teresa Johnson)
- Cc: reply at codereview dot appspotmail dot com, gcc-patches at gcc dot gnu dot org
- Date: Tue, 24 Apr 2012 18:13:56 -0700
- Subject: Re: [PATCH] Take branch misprediction effects into account when RTL loop unrolling (issue6099055)
- References: <20120424212648.E6B696136C@tjsboxrox.mtv.corp.google.com>
tejohnson@google.com (Teresa Johnson) writes:
> This patch adds heuristics to limit unrolling in loops with branches that may increase
> branch mispredictions. It affects loops that are not frequently iterated, and that are
> nested within a hot region of code that already contains many branch instructions.
>
> Performance tested with both internal benchmarks and with SPEC 2000/2006 on a variety
> of Intel systems (Core2, Corei7, SandyBridge) and a couple of different AMD Opteron systems.
> This improves performance of an internal search indexing benchmark by close to 2% on
> all the tested Intel platforms. It also consistently improves 445.gobmk (with FDO feedback
> where unrolling kicks in) by close to 1% on AMD Opteron. Other performance effects are
> neutral.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu. Is this ok for trunk?
One problem with any unrolling heuristics is currently that gcc has both
the tree level and the rtl level unroller. The tree one is even on at
-O3. So if you tweak anything for one you have to affect both, otherwise the
other may still do the wrong thing(tm).
For some other tweaks I looked into a shared cost model some time ago.
May be still needed.
-Andi
--
ak@linux.intel.com -- Speaking for myself only