> On 12/11/2015 03:05 AM, Richard Biener wrote: > > On Thu, Dec 10, 2015 at 9:08 PM, Jeff Law <l...@redhat.com> wrote: > >> On 12/03/2015 07:38 AM, Richard Biener wrote: > >>> > >>> This pass is now enabled by default with -Os but has no limits on > >>> the amount of stmts it copies. > >> > >> The more statements it copies, the more likely it is that the path > >> spitting will turn out to be useful! It's counter-intuitive. > > > > Well, it's still not appropriate for -Os (nor -O2 I think). -ftracer > > is enabled with -fprofile-use (but it is also properly driven to only > > trace hot paths) and otherwise not by default at any optimization level. > I've just committed a patch to limit to loops we're optimizing for speed and > moved the transformation from -O2 to -O3. > > I put in some instrumentation to see when this was triggering and, as > expected the vast majority of triggers are with very small blocks, 2-3 > statements. But those are probably the least interesting. There's limited > instances where it triggers on large blocks (say > 10 statements). But those > were with GCC sources. I'm going to pull out SPEC and do some > instrumented builds with that, obviously focusing on those benchmarks > where Ajit saw improvements.
I measured spec2000 and spec2006 on Haswell with recent GCC with following options - -Ofast -funroll-loops -flto -static -m64 -march=core-avx2 and saw no visible changes in performance for 2 runs, with and without -fno-split-paths. Note also that there are couple of existing issues with path splitting - PR68541 and PR68522 (which is currently bisected) Thanks, Igor
