[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #11 from Marc Glisse 2012-08-01 15:59:43 UTC --- (In reply to comment #9) > I'm beginning to think this is one of those cases of "Doctor it hurts if I > ..." > that should be closed as WONTFIX. Indeed, might even call it INVALID. Thanks a lot for the investigation and sorry for the bad example. Hopefully the patches you wrote are still useful. > Marc, do you know where the use of the > flatten attribute comes from in your code? Comes from the Eigen library, I'll talk to them about it and see if they can comment. They mostly deal with simple number types (double, float), so the behavior with heavy types might have been unnoticed.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #10 from Richard Guenther 2012-08-01 14:32:15 UTC --- (In reply to comment #9) > clang compiles the test case with attribute((flatten)) because it doesn't > support that attribute (http://llvm.org/bugs/show_bug.cgi?id=7559). > > I'm beginning to think this is one of those cases of "Doctor it hurts if I > ..." > that should be closed as WONTFIX. Marc, do you know where the use of the > flatten attribute comes from in your code? indeed "flatten" will override any inlining heuristic that avoids creating gigant function bodies. Still eventually improving worst-case performance of some of our algorithms sounds good, even if it will never fix all issues that pop up when you for example put flatten on main () ;)
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #9 from Steven Bosscher 2012-08-01 14:24:48 UTC --- clang compiles the test case with attribute((flatten)) because it doesn't support that attribute (http://llvm.org/bugs/show_bug.cgi?id=7559). I'm beginning to think this is one of those cases of "Doctor it hurts if I ..." that should be closed as WONTFIX. Marc, do you know where the use of the flatten attribute comes from in your code?
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #8 from Steven Bosscher 2012-08-01 14:14:11 UTC --- With the attribute((flatten)) removed, the full test case compiles in less than a minute.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #7 from Steven Bosscher 2012-08-01 14:08:01 UTC --- (In reply to comment #6) > The inline heuristics stuff is probably also due to stack-vars handling, > I will look into that. Turns out this is due to the use of attribute((flatten)) on gebp_kernel.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #6 from Steven Bosscher 2012-08-01
12:22:29 UTC ---
With my patch applied, and with a couple of lines commented out at the bottom:
// check >();
// check >();
// check();
// check();
// check();
// check();
and with the compiler patched with the patch from comment #5 and configured as:
$ cat configargs.h
/* Generated automatically. */
static const char configuration_arguments[] = "../trunk/configure
--with-mpfr=/opt/cfarm/mpfr-latest --with-gmp=/opt/cfarm/gmp-latest
--with-mpc=/opt/cfarm/mpc-latest --with-isl=/opt/cfarm/isl-latest
--with-cloog=/opt/cfarm/cloog-latest --enable-languages=c,c++ --disable-nls
--disable-libmudflap --disable-libssp --disable-libitm --disable-multilib
--disable-bootstrap --enable-checking=release";
static const char thread_model[] = "posix";
static const struct {
const char *name, *value;
} configure_default_options[] = { { "cpu", "generic" }, { "arch", "x86-64" } };
I have "TOTAL :8223.99" seconds compile time. Top 10 big spenders:
inline heuristics :6393.58 (78%) usr 175699 kB (27%) ggc
tree loop init : 270.76 ( 3%) usr 242922 kB (37%) ggc
if-conversion : 220.55 ( 3%) usr 3774 kB ( 1%) ggc
integrated RA : 199.12 ( 2%) usr 593696 kB (90%) ggc
reload : 128.67 ( 2%) usr 52399 kB ( 8%) ggc
tree SSA incremental: 195.26 ( 2%) usr 160581 kB (24%) ggc
tree SSA rewrite: 112.87 ( 1%) usr 39761 kB ( 6%) ggc
df live regs: 79.90 ( 1%) usr 0 kB ( 0%) ggc
df live&initialized regs: 77.14 ( 1%) usr 0 kB ( 0%) ggc
out of ssa : 63.59 ( 1%) usr661 kB ( 0%) ggc
The inline heuristics stuff is probably also due to stack-vars handling, I will
look into that.
The loop init stuff is something for Richi.
IRA produces the most garbage, by far, and in fact causes OOM if I do not
comment out those last few lines.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher changed: What|Removed |Added Attachment #27915|0 |1 is obsolete|| --- Comment #5 from Steven Bosscher 2012-07-31 22:59:53 UTC --- Created attachment 27917 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27917 Slighty less broken version of the previous attachment
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #4 from Steven Bosscher 2012-07-31 22:16:58 UTC --- Created attachment 27915 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27915 Speed up stack var conflict matric computation The patch speeds up the conflict matrix computation in three ways: 1. Nested EXECUTE_IF_SET_IN_BITMAP is extremely inefficient. The same conflicts result if one IORs the bitmaps. 2. Self-conflicts should not be recorded (this helps stack_var_conflict_p too). 3. The conflicts matrix can be stored in upper triangular form. Debugging, bootstrapping, testing, and other activities involved in contributing this formally are left as an exercise to the reader... ;-)
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #3 from Steven Bosscher 2012-07-31 20:33:56 UTC --- Time is spent in add_scope_conflicts() in this loop: FOR_EACH_BB (bb) add_scope_conflicts_1 (bb, work, true);
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-31 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #2 from Marc Glisse 2012-07-31 18:47:48 UTC --- (In reply to comment #1) > Are you compiling GCC with --enable-checking=release to do the timings? I first noticed the issue with the compiler provided by debian (4.7.1), which has --enable-checking=release. I then checked with a snapshot from 3 days ago which doesn't have the option, and the results were about the same.
[Bug middle-end/54146] Very slow compile at -O1 (expand vars)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146 --- Comment #1 from Andrew Pinski 2012-07-31 18:38:20 UTC --- Are you compiling GCC with --enable-checking=release to do the timings?
