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. I haven't done more than verify the bitmap
code returns to its prior state with that change.
jeff
