Hi Jiufu, On Thu, Jul 09, 2020 at 04:01:38PM +0800, Jiufu Guo wrote: > Segher Boessenkool <seg...@kernel.crashing.org> writes: > >> But for each single condition, loop unrolling may still be helpful. > >> While, if these conditions are all occur in a loop, it would be more > >> possible to get negative impacts after unrolled. > > > > Yes, but how many loops have *all* these conditions? That is my problem > > with it: it is only tested with one specific loop, and only benefits > > that loop. > > I also encounter a few of this kind of loops, some in hot path of leela > and perlbench, and had negative impact leelar_r (~2%), perlbench(>0.5%), > and also gcc_r. I had a quick count, there are ~500 this kind of loops > occur in specint build.
If the generic code decides to unroll big loops with calls *and* jumps, there is a big problem there? On most targets, it should not unroll loops with calls *at all*, for example. > >> While, actually, here we would need condition to define *complex* loop, > >> where contains call exist (may just 1), branch exist(may 2) and early > >> exit(may 1) at the same time, but each number is not large. > >> Any sugguestions? Thanks. > > > > How many loops have you seen where all those conditions are true, but > > the generic code still decides to unroll things? > Some occur as above said. I use -fopt-info to compare the changed > unroll_adjust_hook to check loops of this kind. But there are a few cases where we *do* want to unroll, you say? What is special about those cases, what do they do differently? Segher
