https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118055
--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Hans-Peter Nilsson <h...@gcc.gnu.org>: https://gcc.gnu.org/g:e5c84fd3c195eb5e553fde84e79dd83712edf732 commit r15-6287-ge5c84fd3c195eb5e553fde84e79dd83712edf732 Author: Hans-Peter Nilsson <h...@axis.com> Date: Mon Dec 16 18:47:03 2024 +0100 testsuite: Force max-completely-peeled-insns=300 for CRIS, PR118055 This handles fallout from r15-6097-gee2f19b0937b5e. A brief analysis shows that the metric used in that code is computed by estimate_move_cost, differentiating on the target macro MOVE_MAX_PIECES (which defaults to MOVE_MAX) which for most "32-bit targets" is 4 and for "64-bit targets" is 8. There are some outliers, like pru, with MOVE_MAX set to 8 but counting as a 32-bit target. So, the main difference for this test-case, which is heavy on 64-bit moves (most targets have "double" mapped to IEEE 64-bit), is between "32-bit" and "64-bit", with the cost up to twice for the former compared to the latter. I see no effective_target_move_max_is_4 or equivalent, and this instance falls below the threshold of adding one, so I'm sticking to a list of targets. For CRIS, it would suffice with 210, but there's no need to be this specific, and it would make the test even more brittle. PR tree-optimization/118055 * gcc.dg/tree-ssa/pr83403-1.c, gcc.dg/tree-ssa/pr83403-2.c: Add cris-*-* to targets passing --param=max-completely-peeled-insns=300.
