[Bug tree-optimization/46957] http://blog.regehr.org/archives/320 Example 1

["hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-16 12:11:26 UTC ---
Yep, it is more hack that proper solution for this particular problem. I
considered implementing this a while ago when I ran into problem that fixing
insn estimates affected unrolling negatively in many testsuite testcases
(previously loads/stores was for free that made us to unroll a lot of loop to
great amounts).

I've seen more complex instances similar to this (like cases where we indexed
by IV var constant array and used result to index another constant array), so I
think it is good idea to implement both solutions. Often important part of loop
gets constant after peeling.

Unroller already can produce a lot of statements since it has logic about what
statements are constant based on IVs and similar stuff, there is/was PR on
that.
We probably want simple hard limit on number of new statements introduced, like
1000.