On 7/27/25 3:35 AM, Artemiy Volkov wrote:
From: Artemiy Volkov <arte...@synopsys.com>
Consider the following (RISC-V) instruction pair:
mul s6,a1,a2
add s6,a4,s6
Without this patch, while handling the second instruction, (a) the
existing chain for s6 will first be closed (upon the terminate_write
action for the input operand), then (b) a new one will be opened (upon
the mark_write action for the output operand). This will likely lead to
the two output operands being different physical registers, breaking the
single-output property required for some macro-op fusion pairs.
This patch, using the single_output_fused_pair_p () predicate introduced
earlier, changes the regrename behavior for such pairs to append the
input and the output operands to the existing chain (as if both actions
were mark_read), instead of breaking the current renaming chain and
starting a new one. This ensures that the output operands of both fused
instructions are kept in the same hard register, and that the
single-output property of the insn pair is preserved.
gcc/ChangeLog:
* regrename.cc (scan_rtx_reg): Handle fused insn pairs.
Signed-off-by: Artemiy Volkov <arte...@synopsys.com>
So this depends on patch #2 of the series, but is independent of patch
#1. AFAICT it's probably a good thing on its own and it's simple.
So I'll conditionally ACK and think we should go ahead and
bootstrap/regression test this on top of the adjusted patch #2. Once
that's done and assuming it passes, I'd want to get patch #2 and #3 into
the trunk without waiting on patch #1.
jeff
