https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125305
--- Comment #4 from chenglulu <chenglulu at loongson dot cn> ---
I think the following modification can fix this bug.
```
diff --git a/gcc/config/loongarch/loongarch-def.cc
b/gcc/config/loongarch/loongarch-def.cc
index 67ed3d286bb..4d14df236d2 100644
--- a/gcc/config/loongarch/loongarch-def.cc
+++ b/gcc/config/loongarch/loongarch-def.cc
@@ -189,13 +189,20 @@ array_tune<int> loongarch_cpu_issue_rate =
array_tune<int> ()
.set (TUNE_LA664, 6)
.set (TUNE_LOONGARCH32, 4);
+/* Currently, all LoongArch64 processors are all out-of-order (OoO) execution
+ engines. Because the hardware handles instruction rescheduling
dynamically,
+ aggressive compile-time static multipass scheduling yields diminishing
+ returns while causing a massive compilation time explosion.
+ Therefore, this value is set to 0 on LoongArch64, effectively disabling
+ the permutation evaluation of instructions in the ready queue.
+ */
array_tune<int> loongarch_cpu_multipass_dfa_lookahead = array_tune<int> ()
- .set (TUNE_NATIVE, 4)
- .set (TUNE_GENERIC, 4)
- .set (TUNE_LOONGARCH64, 4)
- .set (TUNE_LA464, 4)
- .set (TUNE_LA664, 6)
- .set (TUNE_LOONGARCH32, 4);
+ .set (TUNE_NATIVE, 2)
+ .set (TUNE_GENERIC, 2)
+ .set (TUNE_LOONGARCH64, 0)
+ .set (TUNE_LA464, 0)
+ .set (TUNE_LA664, 0)
+ .set (TUNE_LOONGARCH32, 2);
/* Wiring string definitions from loongarch-str.h to global arrays
with standard index values from loongarch-opts.h, so we can
```
