http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Steven Bosscher <steven at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|middle-end |tree-optimization
Summary|Very slow compile at -O1 |Very slow compile with
|(expand vars) |attribute((flatten))
--- Comment #12 from Steven Bosscher <steven at gcc dot gnu.org> 2012-08-02
10:01:03 UTC ---
(In reply to comment #10)
> 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 () ;)
Feel free to have a stab at it, if you must.
It would be great if you could have a look at the patch I attached to this bug
report for stack var conflicts (I'd finish it myself, but I won't have time for
it before September or so).
Oh, and document your loop changes, because loop_optimizer_init accounts for
~20% of the compile time (half of it incorrectly accounted to if-conversion,
I'll post a bunch oftimevar fixes this week).
Note that the flattened functions in themselves do not present much of a
problem to the compiler (not at -O1, anyway), so the problem here is not the
by-passing of the inlining heuristics per-se. It is the flattening operation
itself that causes the compiler to explode. You can only see this by adding a
timevar around flatten_function (I used TV_LOCAL_ALLOC for that, but I'll add a
proper timevar for it :-) because the compiler as-is incorrectly accounts the
time for flatten_function to TV_INLINE_HEURISTICS. There must be something
non-linear in the flattening algorithm. I'm still trying to find out where, but
it's kinda hard to debug a problem with a test case that takes literally hours
to compile :-)
