On 10/25/23 03:21, Roger Sayle wrote:
Hi Jeff,
Many thanks for the review/approval of my fix for PR rtl-optimization/91865.
Based on your and Richard Biener's feedback, I’d like to propose a revision
calling simplify_unary_operation instead of simplify_const_unary_operation
(i.e. Richi's recommendation). I was originally concerned that this might
potentially result in unbounded recursion, and testing for ZERO_EXTEND was
safer but "uglier", but testing hasn't shown any issues. If we do see issues
in the future, it's easy to fall back to the previous version of this patch.
This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures. Ok for mainline?
2023-10-25 Roger Sayle <ro...@nextmovesoftware.com>
Richard Biener <rguent...@suse.de>
gcc/ChangeLog
PR rtl-optimization/91865
* combine.cc (make_compound_operation): Avoid creating a
ZERO_EXTEND of a ZERO_EXTEND.
gcc/testsuite/ChangeLog
PR rtl-optimization/91865
* gcc.target/msp430/pr91865.c: New test case.
I'm not terribly worried about recursion. For the case you want to
handle, it's going to be picked up by the call to
simplify_const_unary_operation at the start of simplify_unary_operation.
It's only if that fails that we call into simplify_unary_operation_1.
The only thing that even comes close to worrisome to me in this space is
the asserts in do_SUBST. But I don't think your patch is likely to make
the problems with those asserts any worse than they already are.
OK for the trunk.
Jeff
