This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR38785] Throttle PRE at -O3
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Maxim Kuvyrkov <maxim at codesourcery dot com>
- Cc: Steven Bosscher <stevenb dot gcc at gmail dot com>, Joern Rennecke <joern dot rennecke at arc dot com>, gcc-patches Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 18 Apr 2012 11:17:40 +0200
- Subject: Re: [PATCH, PR38785] Throttle PRE at -O3
- References: <CFDA8E2C-3F19-46AF-A909-A5FD491158CA@codesourcery.com>
On Wed, Apr 18, 2012 at 4:15 AM, Maxim Kuvyrkov <maxim@codesourcery.com> wrote:
> Steven,
> J"orn,
>
> I am looking into fixing performance regression on EEMBC's bitmnp01, and a version of your combined patch attached to PR38785 still works very well. ?Would you mind me getting it through upstream review, or are there any issues with contributing this patch to GCC mainline?
>
> We (CodeSourcery/Mentor) were carrying this patch in our toolchains since GCC 4.4, and it didn't show any performance or correctness problems on x86, ARM, MIPS, and other architectures. ?It also reliably fixes bitmnp01 regression, which is still present in current mainline.
>
> I have tested this patch on recent mainline on i686-linux-gnu with no regressions. ?Unless I hear from you to the contrary, I will push this patch for upstream review and, hopefully, get it checked in.
>
> Previous discussion of this patch is at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00250.html
The addition of -ftree-pre-partial-partial is ok if you change its name to
-ftree-partial-pre and add documentation to invoke.texi.
+ /* Assuming the expression is 50% anticipatable, we have
+ to multiply the number of insertions needed by two for a cost
+ comparison. */
why assume 50% anticipatibility if you can compute the exact
anticipatibility?
+ if (!optimize_function_for_speed_p (cfun)
please look at how I changed regular PRE to look at whether we want to
optimize the path which has the redundancy for speed via
optimize_edge_for_speed_p. The same surgerly should be applied to
PPRE.
Thanks,
Richard.
> Thank you,
>
> --
> Maxim Kuvyrkov
> CodeSourcery / Mentor Graphics
>