CRIS: Disable late-combine by default, related PR115883

With late-combine, performance for coremark compiled for cris-elf
regresses 2.6% by performance and by size 0.4%, measured at
r15-2005-g13757e50ff0b, when compiled with "-O2 -march=v10".

Earlier, at r15-1880-gce34fcc572a0, numbers were by performance 3.2%
and by size 0.4%, even with the proposed patch to PR115883 (TL;DR: a
presumed bug in LRA or combine exposed by late-combine).  Without that
patch, about the same performance results (at that revision).
Similarly around the late-combine commit (r15-1579-g792f97b44ffc5e).

I briefly looked at the performance regression for coremark at
r15-2005-g13757e50ff0b (with/without this patch) as far as seeing that
the stack-frame grew larger (maxing out on hard registers and needing
one more slot) for at least two of the top three* functions that
regressed the most in terms of cycles per call:
matrix_mul_matrix_bitextract (in coremark, 17% slower) and __subdf3
(in libgcc, 6.7% slower).  That makes sense when considering that
late-combine "naturally" stretches register life-times.  But, looking
at late_combine::combine_into_uses and late_combine::optimizable_set,
nothing stood out to me.  I guess there's improvement opportunities in
late_combine::check_register_pressure.

(*) I opted not to look at _dtoa_r (in newlib) mostly because it's
boring and always shows up when something in gcc goes sideways.  (It
maxes out on hard registers and is big.  End of story.)

Note that the change of default is done in the
TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE worker, not in the
TARGET_OPTION_OVERRIDE worker for reasons stated in the
comment.

	* config/cris/cris.cc (cris_option_override_after_change): New
	function.  Disable late-combine by default.
	(cris_option_override): Call the new function.

0 files changed, 0 insertions, 0 deletions