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

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> 2012-08-02 10:35:56 UTC ---
On Thu, 2 Aug 2012, steven at gcc dot gnu.org wrote:

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

It looks sensible - I hope Micha will pick it up though, I'll ping him
personally.

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

It's on my list of things (for stage3, I really want to push more invasive
cleanups for stage1 ... heh).

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

I suppose it's the old issue that we update fibheap keys along each
inlining decision - and with flatten there are just very many ... Honza?
It also seems we flatten depth-first (thus inline leafs) instead of
the other way around:

      orig_callee = callee;
      inline_call (e, true, NULL, NULL);
      if (e->callee != orig_callee)
        orig_callee->symbol.aux = (void *) node;
      flatten_function (e->callee, early);
      if (e->callee != orig_callee)
        orig_callee->symbol.aux = NULL;

This means we will materialize all intermediate flattenings in
functions that will not be reclaimed, right?  flattening foo
should inline everything into foo, but not affect remaining
callee bodies.

Richard.