> On 9 Oct 2026, at 09:36, xiezhiheng <[email protected]> wrote:
>
>> -----Original Message-----
>> From: Kyrylo Tkachov <[email protected]>
>> Sent: Monday, September 21, 2026 5:16 PM
>> To: Richard Biener <[email protected]>
>> Cc: xiezhiheng <[email protected]>; Tamar Christina
>> <[email protected]>; Richard Earnshaw
>> <[email protected]>; [email protected]
>> Subject: Re: [PATCH] sched: Cap max_lookahead_tries
>>
>>
>>
>>> On 21 Sep 2026, at 11:07, Richard Biener <[email protected]> wrote:
>>>
>>> On Sun, Sep 20, 2026 at 3:51 PM Kyrylo Tkachov <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>>> On 20 Sep 2026, at 05:43, xiezhiheng <[email protected]> wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Richard Biener <[email protected]>
>>>>>> Sent: Thursday, September 10, 2026 8:36 PM
>>>>>> To: xiezhiheng <[email protected]>
>>>>>> Cc: [email protected]
>>>>>> Subject: Re: [PATCH] sched: Cap max_lookahead_tries
>>>>>>
>>>>>> On Thu, Sep 10, 2026 at 2:28 PM xiezhiheng <[email protected]> wrote:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Richard Biener <[email protected]>
>>>>>>>> Sent: Thursday, September 10, 2026 5:51 PM
>>>>>>>> To: xiezhiheng <[email protected]>
>>>>>>>> Cc: [email protected]
>>>>>>>> Subject: Re: [PATCH] sched: Cap max_lookahead_tries
>>>>>>>>
>>>>>>>> On Thu, Sep 10, 2026 at 10:22 AM xiezhiheng <[email protected]>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> In the AArch64 backend, dfa_lookahead generally returns issue_rate,
>>>>>>>>> so max_lookahead_tries is set to 100 * issue_rate ** issue_rate.
>>>>>>>>> As issue_rate values for modern AArch64 cores increase, this can
>>>>>>>>> become
>>>>>>>>> very large. For example, the hip12 core has an issue_rate of 8, which
>>>>>>>>> makes max_lookahead_tries 1,677,721,600 and causes very long compile
>>>>>>>>> times.
>>>>>>>>> Another example is Cortex-X925, whose issue_rate is 10,
>>>>>>>>> this causes an overflow in the computation, and max_lookahead_tries
>>>>>>>>> ends up
>>>>>>>>> being 0. Therefore, this patch caps max_lookahead_tries at 1,000,000.
>>>>>>>>> Not sure whether this value is appropriate, any comments?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> With issue_rate values on modern cores continuing to increase,
>>>>>>>>> max_lookahead_tries grows exponentially. Cap max_lookahead_tries
>>>>>>>>> to avoid excessively long compile times.
>>>>>>>>>
>>>>>>>>> Bootstrapped and tested on aarch64-linux-gnu and x86_64-linux-gnu, no
>>>>>>>>> regression.
>>>>>>>>
>>>>>>>> ISTR seeing similar things in a bugzilla when x86 bumped issue_rate
>>>>>>>> for some cores.
>>>>>>>> There's some analysis in the bug:
>>>>>>>>
>>>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119010
>>>>>>>
>>>>>>> Thanks for the info! So maybe the root cause is that some instructions
>>>>>>> are
>>>>>>> missing reservations? I'll continue investigating in that direction.
>>>>>
>>>>> Hi aarch64 port maintainers,
>>>>>
>>>>> I have a few questions I'd like to ask. After some analysis, I found that
>>>>> when the first loop in max_issue reaches max_lookahead_tries, the state
>>>>> is as follows:
>>>>>
>>>>> ;; max_issue among 17 insns: 500:351:prio=0 499:350:prio=1
>>>>> 345:333:prio=1 349:253:prio=1
>> 341:251:prio=1 338:250:prio=1 253:262:prio=4 266:244:prio=4
>> 264:243:prio=4 254:240:prio=4 249:236:prio=4
>> 247:235:prio=4 238:258:prio=5 232:228:prio=5 234:225:prio=5
>> 215:229:prio=5 221:217:prio=5
>>>>>
>>>>> ;; | 500 | 0 | x23=x23+0xa8 ca57_sx1|ca57_sx2
>>>>> ;; | 499 | 1 | {cc=cmp(x26-0x1,0);x26=x26-0x1;} ca57_sx1|ca57_sx2
>>>>> ;; | 345 | 1 | x3=x19+[176, 176] ca57_sx1|ca57_sx2
>>>>> ;; | 349 | 1 | x1=x19+[208, 208] ca57_sx1|ca57_sx2
>>>>> ;; | 341 | 1 | x5=x19+[144, 144] ca57_sx1|ca57_sx2
>>>>> ;; | 338 | 1 | x6=x19+[128, 128] ca57_sx1|ca57_sx2
>>>>> ;; | 253 | 4 | v1=v27 0>>const_vector nothing
>>>>> ;; | 266 | 4 | v16=v29 0>>const_vector nothing
>>>>> ;; | 264 | 4 | v17=v30 0>>const_vector nothing
>>>>> ;; | 254 | 4 | v22=v26 0>>const_vector nothing
>>>>> ;; | 249 | 4 | v5=v29 0>>const_vector nothing
>>>>> ;; | 247 | 4 | v6=v30 0>>const_vector nothing
>>>>> ;; | 238 | 5 | v19=v27 0>>const_vector nothing
>>>>> ;; | 232 | 5 | v0=v30 0>>const_vector nothing
>>>>> ;; | 234 | 5 | v21=v29 0>>const_vector nothing
>>>>> ;; | 215 | 5 | x0=x20+[128, 128] ca57_sx1|ca57_sx2
>>>>> ;; | 221 | 5 | x2=x20+[176, 176] ca57_sx1|ca57_sx2
>>>>>
>>>>> (insn 253 245 255 10 (set (reg:VNx2DI 33 v1)
>>>>> (lshiftrt:VNx2DI (reg:VNx2DI 59 v27)
>>>>> (const_vector:VNx2DI repeat [
>>>>> (const_int 48 [0x30])
>>>>> ]))) "test.c":11:24 discrim 102400 8708
>>>>> {aarch64_vlshrvnx2di3_const}
>>>>> (nil))
>>>>>
>>>>> I found that SVE as a whole does not seem to have any reservations set,
>>>>> which leads to a large number of "nothing" entries. This may affect the
>>>>> execution time of traditional DFA scheduling. Has this issue been noticed
>>>>> before?
>>>>> Also, I noticed that dispatch scheduling has been introduced in the
>>>>> AArch64 backend. Is this a new solution to the missing SVE reservations?
>>>>>
>>>>
>>>> Yes, this known and (sort of) deliberate. We didn’t want to create a
>>>> fine-grained scheduling type classification for SVE types as there
>> are a large amount of SVE instructions. For all aarch64 cores where SVE
>> performance matters the CPUs are aggressively OoO so we
>> don’t have evidence that DFA scheduling would be worth the effort and
>> maintenance burden of creating a scheduling type scheme for
>> SVE instructions. For some cores like Neoverse V2, Olympus we have taken the
>> dispatch scheduling scheme that does not care about the
>> DFA type, as you noticed. It uses a much more coarse-grained sve_type to
>> help its classification.
>>>>
>>>> In theory, some of the smaller recent cores have SVE2 may want to do DFA
>>>> scheduling, but I guess nobody has considered it valuable
>> enough to be worth the effort I described above.
>>>
>>> But it causes compile-time blow-up for scheduling. So maybe the
>>> schedulers behavior for insns w/o reservation
>>> should be improved somehow, possibly by not re-scheduling those at all?
>>>
>>
>> I think for aarch64 the simplest workaround would be to treat insns with an
>> sve_type (i.e. only used for dispatch-scheduling) as a
>> standard basic Neon instruction.
>> This is what we did for the armv8.X SIMD instructions in
>> config/arm/cortex-a57.md (which is the basis for most DFA aarch64
>> descriptions):
>> ;; If it doesn't match any of the above that we want to treat specially but
>> is
>> ;; still a NEON type, treat it as a basic NEON type. This is better than
>> ;; dropping it on the floor and making no assumptions about it whatsoever.
>>
>> (eq_attr "is_neon_type" "yes”)
>> (const_string "neon_arith_basic")]
>>
>
>
> Sorry for the late reply, I was on vacation. Treating all SVE instructions as
> basic NEON instructions
> should help me solve the problem. The patch would roughly be as follows,
> Reuse sve_type, but only use it to identify whether an instruction is an SVE
> instruction, and map
> it to neon_arith_basic. How does this approach sound?
>
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 7c8915ec389..459bc7f212d 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -704,6 +704,26 @@ (define_attr "sve_type"
> sve_crypto_sha3"
> (const_string "none"))
>
> +(define_attr "is_sve_type" "yes,no"
> + (if_then_else (eq_attr "sve_type"
> + "none,\
> + sve_pred_logical,sve_pred_cnt_ctrl,sve_pred_cnt_scalar,sve_pred_misc,\
> + sve_pred_vec,\
> +
> sve_fp_arith,sve_fp_mul,sve_fp_assoc_add,sve_fp_cmp,sve_fp_cvt,sve_fp_log,\
> + sve_fp_exp,sve_fp_div,sve_fp_sqrt,sve_fp_reduc,sve_fp_misc,\
> + sve_int_general,sve_int_shift,sve_int_mul,sve_int_dot,sve_int_cmp_set,\
> + sve_int_extend,sve_int_extract,sve_int_cvt,sve_int_div,sve_int_index,\
> + sve_int_match,sve_int_recip_est,sve_int_reduc,sve_int_accum,\
> + sve_int_pmul,sve_int_bit_perm,\
> + sve_load_pred,sve_load_1reg,sve_load_2reg,sve_load_3reg,sve_load_4reg,\
> + sve_gatherload_32,sve_gatherload_64,\
> +
> sve_store_pred,sve_store_1reg,sve_store_2reg,sve_store_3reg,sve_store_4reg,\
> + sve_scatterstore_32,sve_scatterstore_64,\
> + sve_ffr,\
> + sve_crypto_sha3")
> + (const_string "yes")
> + (const_string "no")))
> +
> ;; -------------------------------------------------------------------
> ;; Pipeline descriptions and scheduling
> ;; -------------------------------------------------------------------
> diff --git a/gcc/config/arm/cortex-a57.md b/gcc/config/arm/cortex-a57.md
> index 07003422e01..ef3334a8e99 100644
> --- a/gcc/config/arm/cortex-a57.md
> +++ b/gcc/config/arm/cortex-a57.md
> @@ -241,6 +241,9 @@ (define_attr "cortex_a57_neon_type"
> ;; still a NEON type, treat it as a basic NEON type. This is better than
> ;; dropping it on the floor and making no assumptions about it whatsoever.
> (eq_attr "is_neon_type" "yes")
> + (const_string "neon_arith_basic")
> +
> + (eq_attr "is_sve_type" "yes")
> (const_string "neon_arith_basic")]
I think you can just test if sve_type is not “none” and avoid the big
is_sve_type definition above?
> (const_string "unknown")))
>
>
> One more thing: I will later submit the pipeline for the hip12 core.
> Would you recommend doing this only in hip12.md, or enabling it
> in the widely used cortex-a57.md/cortex-a53.md as well?
>
I think doing this more widely for cortex-a57.md/cortex-a53.md is fine.
Thanks,
Kyrill
> Thanks,
> Xie Zhiheng
>
>
>>
>>>> Thanks,
>>>> Kyrill
>>>>
>>>>
>>>>> Many thanks!
>>>>> Xie Zhiheng
>>>>>
>>>>>
>>>>>>
>>>>>> I think so.
>>>>>>
>>>>>>> Also, the overflow in the max_lookahead_tries calculation is still
>>>>>>> there.
>>>>>>> Maybe I should send a separate patch to change its type from int to
>>>>>>> int64_t?
>>>>>>
>>>>>> Yes, I think that makes sense.
>>>>>>
>>>>>> Richard.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>> gcc/ChangeLog:
>>>>>>>>>
>>>>>>>>> * haifa-sched.cc (max_issue): cap max_lookahead_tries
>>>>>>>>> ---
>>>>>>>>> gcc/haifa-sched.cc | 5 +++--
>>>>>>>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>> diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
>>>>>>>>> index 879749e9785..7f3fd5b496a 100644
>>>>>>>>> --- a/gcc/haifa-sched.cc
>>>>>>>>> +++ b/gcc/haifa-sched.cc
>>>>>>>>> @@ -5956,9 +5956,10 @@ max_issue (struct ready_list *ready, int
>>>>>>>>> privileged_n, state_t state,
>>>>>>>>> /* Init MAX_LOOKAHEAD_TRIES. */
>>>>>>>>> if (max_lookahead_tries == 0)
>>>>>>>>> {
>>>>>>>>> - max_lookahead_tries = 100;
>>>>>>>>> + int64_t max_tries = 100;
>>>>>>>>> for (i = 0; i < issue_rate; i++)
>>>>>>>>> - max_lookahead_tries *= dfa_lookahead;
>>>>>>>>> + max_tries *= dfa_lookahead;
>>>>>>>>> + max_lookahead_tries = MIN (max_tries, (int64_t) 1000000);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> /* Init max_points. */
