[Bug tree-optimization/57249] Unrolling too late for inlining

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-05-13
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
There is the long-standing idea of moving cunrolli from after IPA inlining
into the early optimization pipeline.  But we'd have to tame it down
quite a bit to make it viable there.  Note that originally cunrolli was
desiged to remove C++ abstraction penalty from code like

template <int i>
struct S {
  int a[i];
  S() { for (int j = 0; j < i; ++j) a[j] = 0; }
};

for small i (tramp3d has code similar to the above for i == 3 and uses
template metaprogramming to avoid loops and force unrolling by abusing
the inliner ...)

In the mean time cunrolli does more (which is not necessarily good).

Note that I wouldn't unroll loops with calls in them (eventually
special-casing that indirect-call-via-global-constructor-with-initializer...)

For early optimizations unrolling should only be applied if the code size
shrinks by the transform.

Btw, this case could be handled by value-numbering / folding, too, given
that all map[]'s elements have the same value.  But the testcase is very
very artificial so this will never help a real case.