On Dec 9, 2021, Jeff Law <jeffreya...@gmail.com> wrote: >> I found a similar pattern of issuing clobbers for multi-word moves, but >> not when reload_in_progress, in expr.c:emit_move_complex_parts. I don't >> have a testcase, but I'm tempted to propose '!lra_in_progress &&' for it >> as well. Can you think of any reason not to?
> The only reason I can think of is we're in stage3 :-) It'd be a lot > easier to green light that if we could trigger an issue. I have not found the cycles to try to construct a testcase to trigger the issue, but before moving on, I have regstrapped this on x86_64-linux-gnu, so, at least for now, I propose it for the next release cycle. Ok to install then? [PR103302] skip multi-part clobber during lra for complex parts too From: Alexandre Oliva <ol...@adacore.com> As with the earlier patch, avoid emitting clobbers that we used to avoid during reload also during LRA, now when moving complex multi-part values. We don't have a testcase for this one. for gcc/ChangeLog PR target/103302 * expr.c (emit_move_complex_parts): Skip clobbers during lra. --- gcc/expr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/expr.c b/gcc/expr.c index 0365625e7b835..30d1735ec29ce 100644 --- a/gcc/expr.c +++ b/gcc/expr.c @@ -3736,7 +3736,7 @@ emit_move_complex_parts (rtx x, rtx y) /* Show the output dies here. This is necessary for SUBREGs of pseudos since we cannot track their lifetimes correctly; hard regs shouldn't appear here except as return values. */ - if (!reload_completed && !reload_in_progress + if (!reload_completed && !reload_in_progress && !lra_in_progress && REG_P (x) && !reg_overlap_mentioned_p (x, y)) emit_clobber (x); -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>