On 5/25/23 03:22, Richard Sandiford wrote:
Jin Ma <ji...@linux.alibaba.com> writes:
When the last insn1 of BB1 and the first insn2 of BB2 are fusion, insn2 will
clear all dependencies in the function chain_to_prev_insn, resulting in insn2
may mov to any BB, and the program calculation result is wrong.
gcc/ChangeLog:
* sched-deps.cc (sched_macro_fuse_insns): Insns should not be fusion
in different BB blocks
---
gcc/sched-deps.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/sched-deps.cc b/gcc/sched-deps.cc
index 2aa6623ad2e..998fe930804 100644
--- a/gcc/sched-deps.cc
+++ b/gcc/sched-deps.cc
@@ -2833,7 +2833,7 @@ sched_macro_fuse_insns (rtx_insn *insn)
compile time complexity. */
if (DEBUG_INSN_P (insn))
return;
- prev = prev_nonnote_nondebug_insn (insn);
+ prev = prev_nonnote_nondebug_insn_bb (insn);
if (!prev)
return;
Huh, kind-of impressed we managed to go so long without hitting this.
Yea. I suspect a lot of the fusion cases we've handled until now have
been more focused on things like compare+branch on x86 which are going
to be in the same block.
The patch is OK, thanks (and for branches too if necessary).
I don't think Jin has commit privs, so I'll push it to the trunk and
active release branches.
jeff
