ok. David
On Tue, Jan 21, 2014 at 4:46 PM, Sriraman Tallam <tmsri...@google.com> wrote: > On Tue, Jan 21, 2014 at 2:49 PM, Xinliang David Li <davi...@google.com> wrote: >> I think it might be better to introduce a new parameter for max peel >> insn at O2 (e.g, call it MAX_O2_COMPLETELY_PEEL_INSN or >> MAX_DEFAULT_...), and use the same logic in your patch to override the >> MAX_COMPLETELY_PEELED_INSN parameter at O2). >> >> By so doing, we don't need to have a hard coded factor of 2. > > Patch attached with that change. > > Sri > >> >> In the longer run, we really need better cost/benefit analysis, but >> that is independent. >> >> David >> >> On Tue, Jan 21, 2014 at 1:49 PM, Sriraman Tallam <tmsri...@google.com> wrote: >>> Hi, >>> >>> Currently, tree unrolling pass(cunroll) does not allow any code >>> size growth in O2 mode. Code size growth is permitted only if O3 or >>> funroll-loops/fpeel-loops is used. I have created a patch to allow >>> partial code size increase in O2 mode. With funroll-loops the maximum >>> allowed code growth is 400 unrolled insns. I have set it to 200 >>> unrolled insns in O2 mode. This patch improves an image processing >>> benchmark by 20%. It improves most benchmarks by 1-2%. The code size >>> increase is <1% for all the benchmarks except the image processing >>> benchmark which increases by 6% (perf improves by 20%). >>> >>> I am working on getting this patch reviewed for trunk. Here is >>> the disussion on this: >>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02643.html I have >>> incorporated the comments on making the patch simpler. I will >>> follow-up on that patch to trunk by also getting data on limiting >>> complete peeling with O2. >>> >>> Is this ok for the google branch? >>> >>> Thanks >>> Sri
