[PATCH] RISC-V: In pipeline scheduling, insns should not be fusion in different BB blocks.
Jeff Law
jeffreyalaw@gmail.com
Thu May 25 13:46:05 GMT 2023
On 5/25/23 03:22, Richard Sandiford wrote:
> Jin Ma <jinma@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
More information about the Gcc-patches
mailing list