On 9/19/26 9:43 PM, xiezhiheng 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?
A lot of "nothing" reservations is bad and indicates there are many
insns that do not map to a unit within the DFA. You'll get some unusual
results if you have a lot of "nothing" reservations in the DFA.
The RISC-V port fights this problem by ensuring that every insn always
has a mapping to a functional unit in the DFA. That has avoided
problems with "nothing" reservations, but introduces a fairly high
maintenance burden. The key issue most ports (and I assume aarch64 is
no different here) can ask for code that runs on chip X, but a scheduler
model for chip Y. So the scheduler model for Y must cover not just the
instructions for Y, but the instructions for any X.
Jeff
