[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