[PATCH] D21429: Make the insertion of predicate deps in the schedule graph not quadratic in the number of predicate deps.

[Andrew Trick via llvm-commits]

atrick added a comment.

TL;DR: The DAG builder is never supposed to form "insane" DAGs.

Why do we have a compile-time stress test checked into unit tests if we don't want to bloat make check time? This test should be attached to a bug report instead!

It's well understood that scheduling DAGs are quadratic if they naively represent all dependencies. That is a problem regardless of how the predecessor/successor edges are uniqued. We don't want to use quadratic space either.

The normal strategy for dealing with the DAG size is pinch off the dependencies at some reasonable limit. Why isn't that happening? For example, that's why we don't include stack pointer manipulation in the DAG. Are these register or memory dependencies? Support for alias analysis was recently enabled, and I expect to see situations like this as fall-out. If that's the case, the fix is to teach the DAG builder to better limit the number of memory dependencies that are being tracked.

The obvious downside to this patch is increasing the size of the DAG and constant overhead. That needs to be measured. I don't think the common case should be penalized, particularly because there are other ways to prevent pathological behavior in the DAG builder.

Sorry I don't have time to investigate this test case. I wish I did.

[Note: There are a lot of innefficiencies in the scheduling DAG because it's shared with ISEL. What makes that especially painful is that it's quite silly for ISEL to build this DAG at all].


http://reviews.llvm.org/D21429