Jeff Law wrote: > On 11/23/14 15:22, Sebastian Pop wrote: > >Jeff Law wrote: > >>>PS: I have run some perf analysis with the patch: > >>>- on a bootstrap of GCC I see 3209 FSM jump threads > >>>- libpng and libjpeg contain FSM jump threads, the perf increase is in the > >>>1% > >>> (measured on simulators and reduced data sets) > >>>- coremark gets jump threaded (as expected) > >>>- I'm setting up the llvm test-suite and I will report perf differences > >>So that's *far* more jump threads than I would expect this to find > >>in a bootstrap of GCC -- like 3 orders of magnitude more than I'd > >>expect to find. > > > >The second patch attached limits the search for FSM jump threads to loops. > >With > >that patch, we are now down to 470 jump threads in an x86_64-linux bootstrap > >(and 424 jump threads on powerpc64-linux bootstrap.) > [ ... ] > > So why are we returning -1 (block should not be duplicated and not > suitable for a joiner) at the end of thread_through_normal_block? > > > /* When COND cannot be simplified, try to find paths from a control > statement back through the PHI nodes which would affect > that control > statement. */ > vec<basic_block, va_gc> *bb_path; > vec_alloc (bb_path, n_basic_blocks_for_fn (cfun)); > vec_safe_push (bb_path, e->dest); > hash_set<gimple> *visited_phis = new hash_set<gimple>; > > max_threaded_paths = PARAM_VALUE (PARAM_MAX_FSM_THREAD_PATHS); > fsm_find_control_statement_thread_paths (cond, visited_phis, > bb_path); > > delete visited_phis; > vec_free (bb_path); > > return -1; > > Returning -1 (instead of 0) says stop, there's no possibility to > threading something on that path. I think that's suppressing some > profitable jump threads.
Thanks for spotting this. > I haven't done more than verify the > bitmap code returns to its prior state with that change. I removed the return -1 and started a bootstrap on powerpc64-linux. I will report the valgrind output. Thanks, Sebastian
