> 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.
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. */
