> On 16 Dec 2025, at 04:36, Maxim Kuvyrkov <[email protected]> wrote:
> 
> Hi Kyrill,
> 
> Please push both patches.
> 

Thanks for your help, Maxim.
Now pushed.
Kyrill

> Thanks!
> 
> --
> Maxim Kuvyrkov
> https://www.linaro.org
> 
>> On Dec 11, 2025, at 00:13, Kyrylo Tkachov <[email protected]> wrote:
>> 
>> 
>> 
>>> On 4 Dec 2025, at 09:48, Richard Biener <[email protected]> wrote:
>>> 
>>> On Thu, 4 Dec 2025, Kyrylo Tkachov wrote:
>>> 
>>>> Hi Maxim
>>>> 
>>>>> On 25 Nov 2025, at 08:01, Maxim Kuvyrkov <[email protected]> 
>>>>> wrote:
>>>>> 
>>>>> Hi Jennifer,
>>>>> Hi Kyrylo,
>>>>> 
>>>>> The logic behind this patch is sound, but I suggest doing this fix in 
>>>>> choose_ready() to avoid proliferation of special-casing of 
>>>>> SCHED_GROUP_P() -- see attached patch.  As far as I can see, the attached 
>>>>> version has the same semantics as your original patch -- please let me 
>>>>> know if that's not the case.
>>>>> 
>>>>> I don't have approval acl's on scheduler patches, so would one of 
>>>>> maintainers please rubber-stamp this?
>>>> 
>>>> Thanks for this. I’m happy with your patch as well. I’m also petitioning 
>>>> the maintainers for an approval on this :)
>>>> Kyrill
>>> 
>>> OK.
>> 
>> Thanks Richard.
>> Maxim, would you like to push your patch please?
>> Otherwise I’ll push both patches to trunk next week.
>> Thanks,
>> Kyrill
>> 
>>> 
>>> Richard.
>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> [Slightly off-topic]
>>>>> The attached patch also makes it explicit that dispatch scheduling is 
>>>>> active only when lookahead multipass scheduling is disabled 
>>>>> (dfa_lookahead <= 0).  I wonder whether the two can co-exist or whether 
>>>>> they are mutually exclusive.
>>>>> 
>>>>> Looking at i386 backend I see that dfa_lookahead==0 for pre-reload 
>>>>> scheduling, but enabled for post-reload.  This means the dispatch 
>>>>> scheduling is done before reload for BDVERx, but not after.
>>>>> 
>>>>> For aarch64, dispatch scheduling seems to be active when sched_fusion is 
>>>>> enabled AND AARCH64_EXTRA_TUNE_DISPATCH_SCHED -- this currently means 
>>>>> Neoverse-V2 both before or after reload.
>>>>> 
>>>>> Kind regards,
>>>>> 
>>>>> --
>>>>> Maxim Kuvyrkov
>>>>> https://www.linaro.org
>>>>> 
>>>>>> On Nov 21, 2025, at 23:41, Kyrylo Tkachov <[email protected]> wrote:
>>>>>> 
>>>>>> Adding a couple more global reviewers on CC.
>>>>>> 
>>>>>> Ping on this patch. We need it to avoid a performance regression 
>>>>>> relating to fusing instructions when enabling dispatch scheduling for a 
>>>>>> new core in AArch64.
>>>>>> 
>>>>>> https://gcc.gnu.org/pipermail/gcc-patches/2025-October/698465.html
>>>>>> Thanks,
>>>>>> Kyrill
>>>>>> 
>>>>>> 
>>>>>>> On 23 Oct 2025, at 16:18, Jennifer Schmitz <[email protected]> wrote:
>>>>>>> 
>>>>>>> While looking at codegen effects of dispatch scheduling in the aarch64
>>>>>>> backend, I noticed that many fusion pairs were split, in particular
>>>>>>> CMP+CSEL and CMP+CSET.
>>>>>>> The reason is that the information that an instruction is part of a
>>>>>>> fusion pair is not considered in the function
>>>>>>> 
>>>>>>> /* This function returns a candidate satisfying dispatch constraints 
>>>>>>> from
>>>>>>> the ready list.  */
>>>>>>> static rtx_insn *
>>>>>>> ready_remove_first_dispatch (struct ready_list *ready)
>>>>>>> 
>>>>>>> I propose to fix this issue by adding a check for SCHED_GROUP_P (insn)
>>>>>>> (this is true for the second instruction in a fusion pair) such that
>>>>>>> the instruction is scheduled immediately after its partner without
>>>>>>> considering dispatch constraints. With this change I did not see
>>>>>>> splitting of fusion pairs anymore.
>>>>>>> 
>>>>>>> The patch was bootstrapped and tested on aarch64-linux-gnu, no 
>>>>>>> regression.
>>>>>>> OK for trunk?
>>>>>>> 
>>>>>>> Signed-off-by: Jennifer Schmitz <[email protected]>
>>>>>>> 
>>>>>>> gcc/
>>>>>>> * haifa-sched.cc (ready_remove_first_dispatch): Add check for
>>>>>>> fusion pairs.
>>>>>>> ---
>>>>>>> gcc/haifa-sched.cc | 1 +
>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>> 
>>>>>>> diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
>>>>>>> index 63eb06b2d82..163b538c528 100644
>>>>>>> --- a/gcc/haifa-sched.cc
>>>>>>> +++ b/gcc/haifa-sched.cc
>>>>>>> @@ -9224,6 +9224,7 @@ ready_remove_first_dispatch (struct ready_list 
>>>>>>> *ready)
>>>>>>>  || !INSN_P (insn)
>>>>>>>  || INSN_CODE (insn) < 0
>>>>>>>  || !active_insn_p (insn)
>>>>>>> +      || SCHED_GROUP_P (insn)
>>>>>>>  || targetm.sched.dispatch (insn, FITS_DISPATCH_WINDOW))
>>>>>>> return ready_remove_first (ready);
>>>>>>> 
>>>>>>> -- 
>>>>>>> 2.34.1
>>>>>>> 
>>>>>> 
>>>>> <dispatch-sched-group.diff>
>>>> 
>>>> 
>>> 
>>> -- 
>>> Richard Biener <[email protected]>
>>> SUSE Software Solutions Germany GmbH,
>>> Frankenstrasse 146, 90461 Nuernberg, Germany;
>>> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG 
>>> Nuernberg)
> 
> 

Reply via email to