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
> 

Reply via email to