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