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