Hi,
Segher Boessenkool <seg...@kernel.crashing.org> writes: > 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? During tests, if avoid unroll loops if there is call (or early exit). As I remember there are performance downgrade on 1 or 2 benchmarks, but I forget which ones. I check and confirm. BR. Jiufu, > > > Segher
