> 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")]
>> 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. */
