https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #10 from Alexander Monakov ---
Indeed, but OTOH according to bug 84402 comment 58 it caused a noticeable hit
on gimple-match.cc compilation:
733a1b777f16cd397b43a242d9c31761f66d3da8 13th January 2023
sched-deps: do not schedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #9 from Richard Biener ---
As far as I understand the testcase is from fuzzing so not "real", so I think
this proposed "fix" isn't necessary (and it's not a real fix, adding a
setjmp call at the end of the function will restore it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #8 from Alexander Monakov ---
If we want to get rid of the compilation time regression sooner rather than
later, I can suggest limiting my change only to functions that call setjmp:
diff --git a/gcc/sched-deps.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #7 from Jeffrey A. Law ---
Yea, there are various limits on the size of various lists the scheduler
maintains. This looks independent of those various clamps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
--- Comment #6 from Richard Biener ---
Isn't the "scheduling window" limited somehow? Can we impose an upper bound on
the number of dependences by placing a "virtual barrier" when we hit that
limit?
I don't know the structure of the scheduler
