https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89963
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Actually it does - just compile-time isn't linear in the max operations :/ --param max-isl-operations compile-time 100000 0.36s 110000 2.62s 120000 5.35s 130000 15.57s 140000 30.16s 200000 138.96 IIRC I've "tuned" the default so we don't hit the timeout for SPEC 2006 (and that didn't cause any compile-time issues). From looking at the source the number of operations are more related to memory use (allocations trigger one "operations"), the only other "operation" is isl_tab_pivot. The time hog is finishing cut_to_integer_lexmin (which eventually calls isl_tab_pivot multiple times). It seems that when isl_tab_pivot is the driving hog the limit is too high but when it is allocation it works well enough. It looks like ISL should have two different limits, one for memory use and one for time since they are not really comparable. Also looks like (on this testcase at least) ISL-Imath is a lot slower than ISL-gmp (by nearly a factor of 10!).
