On 05/07/2013 07:22 AM, Bill Schmidt wrote:
This handles the unlikely case where there are many different increments
associated with a group of related SLSR candidates, which could result
in poor performance when doing linear searches of the increment vector.
The size of the increment vector is limited to a reasonable constant,
and increments that do not appear in the increment vector are not
processed.
Bootstrapped and tested on powerpc64-unknown-linux-gnu with no new
regressions. Ok for trunk?
Thanks,
Bill
2013-05-06 Bill Schmidt <wschm...@linux.vnet.ibm.com>
* gimple-ssa-strength-reduction.c (MAX_INCR_VEC_LEN): New constant.
(incr_vec_index): Return -1 if increment not found.
(create_add_on_incoming_edge): Assert if increment not found.
(record_increment): Limit number of increments recorded.
(all_phi_incrs_profitable): Return false if an increment not found.
(replace_profitable_candidates): Don't process increments that were
not recorded.
(analyze_candidates_and_replace): Limit size of incr_vec.
BTW, I'd be interested to know if anyone has poked at the SH port to see
if SLSR eliminates the need for reload_cse_move2add?
Who does SH stuff these days?
jeff
