[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 23 Jan 2017, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445
> 
> --- Comment #19 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> One change that would make sense to me is to always thread when there is a
> non-cold block on the path: we are not only improving the path taken when
> threading but because we eliminate incoming edges we also permit better
> optimization of non-thread path later.
> 
> This way we thread the branch, because there is still non-cold BB on a way.
> 
> On related note, I have noticed that we give up on about 30% of jump threads in
> early optimization because of:
> 
>        /* Skip edges pointing outside the current loop.  */
>        if (!arg || var_bb->loop_father != bbi->loop_father)
>         continue;
> 
> This is very common case such as in:
> char *c;
> int t()
> {
>   for (int i=0;i<5000;i++)
>     c[i]=i;
> }
> 
> before loop header copying there is threadable branch at first iteration.
> Threading it before profile construction would be quite desirable.
> 
> There seem to be code deciding on loops when checking path profitability. It
> seems to me that at least the code can be adjusted to accept thread starting by
> loop header when there is only single edge in becausee that can't make
> irreducible loops?

But it will rotate the loop and thus change the loop header block?  Then
we need to make sure to preserve that properly to not destroy loop
annotations by removing/rediscovering the loop.

Also we need to make sure to not repeatedly peel the loop via such 
mechanism.