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.
