[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%) since r13-5154-g733a1b777f1
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 pseudos across calls [PR108117] (Alexander Monakov) Stage 2: +14% Stage 3: +9% In any case, if the proposed band-aid is unnecessary, that's fine with me.
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%) since r13-5154-g733a1b777f1
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).
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%) since r13-5154-g733a1b777f1
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 b/gcc/sched-deps.cc
index c23218890f..ae23f55274 100644
--- a/gcc/sched-deps.cc
+++ b/gcc/sched-deps.cc
@@ -3695,7 +3695,7 @@ deps_analyze_insn (class deps_desc *deps, rtx_insn *insn)
CANT_MOVE (insn) = 1;
- if (!reload_completed)
+ if (!reload_completed && cfun->calls_setjmp)
{
/* Scheduling across calls may increase register pressure by
extending
live ranges of pseudos over the call. Worse, in presence of
setjmp
That way we retain the "correctness fix" part of r13-5154-g733a1b777f1 and keep
the previous status quo on normal functions (quadraticness on asms like
demonstrated in comment #5 would also remain).
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%) since r13-5154-g733a1b777f1
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.
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%) since r13-5154-g733a1b777f1
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 or it's dependence analysis framework. In other places where GCC faces this usual quadraticness in dependence analysis we have such limits and try to cope with it as good as we can, worst give up completely.
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261
Alexander Monakov changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu.org
--- Comment #5 from Alexander Monakov ---
It appears sched-deps is O(N*M) given N reg_pending_barriers and M distinct
pseudos in a region (or even a basic block). For instance, on the following
testcase
#define x10(x) x x x x x x x x x x
#define x100(x) x10(x10(x))
#define x1(x) x100(x100(x))
void f(int);
void g(int *p)
{
#if 1
x1(f(*p++);)
#else
x1(asm("" :: "r"(*p++));)
#endif
}
gcc -O -fschedule-insns invokes add_dependence 2 times for each asm/call
after the first. There is a loop
for (i = 0; i < (unsigned)deps->max_reg; i++)
{
struct deps_reg *reg_last = >reg_last[i];
reg_last->sets = alloc_INSN_LIST (insn, reg_last->sets);
SET_REGNO_REG_SET (>reg_last_in_use, i);
}
that registers the insn with reg_pending_barrier != 0 in reg_last->sets of each
pseudo, and then all those reg_last->sets will be inspected on the next
reg_pending_barrier insn.
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Patrick O'Neill changed: What|Removed |Added Attachment #57640|0 |1 is obsolete|| --- Comment #4 from Patrick O'Neill --- Created attachment 57642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57642=edit Raw testcase and headers Thanks for catching that, here's the zip file with actual files in it this time ;)
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #3 from Alexander Monakov --- The first attachment is empty (perhaps you made a non-recursive archive when you meant to recursively zip a directory).
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #2 from Patrick O'Neill --- Created attachment 57641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57641=edit unreduced preprocessed testcase
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.3 CC||amonakov at gcc dot gnu.org, ||pinskia at gcc dot gnu.org
[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114261 --- Comment #1 from Patrick O'Neill --- Created attachment 57640 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57640=edit Raw testcase and headers
