> 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