[Bug tree-optimization/54146] Very slow compile with attribute((flatten))

[steven at gcc dot gnu.org]

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 :-)