On 11/10/2016 06:54 PM, Andrew Pinski wrote: > On Wed, Nov 9, 2016 at 2:13 PM, Pat Haugen <pthau...@linux.vnet.ibm.com> > wrote: >> > The following fixes a problem introduced by my earlier loop unroller >> > patch, https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01612.html. In >> > instances where the niter expr is not reliable we need to still emit an >> > initial peel copy of the loop. >> > >> > Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk? > This fixes the performance regression I reported with the original > patch at https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01224.html .
That's good to hear your performance problem is gone. I'm thinking it's more of a side effect of this patch, which causes differences in basic block frequencies (which then affects decisions based on those frequencies). I'm currently looking at pr78116, that noted a couple degradations after my unroller patches, which I'm also guessing are due to BB frequency changes. We have 2 open pr's on phases that currently mess up BB frequencies, vectorizer (pr77536) and loop unroller (pr68212). -Pat
