On Thu, Feb 7, 2013 at 7:16 PM, Xinliang David Li <davi...@google.com> wrote: > On Thu, Feb 7, 2013 at 9:28 AM, David Edelsohn <dje....@gmail.com> wrote: >> On Thu, Feb 7, 2013 at 11:09 AM, Richard Biener >> <richard.guent...@gmail.com> wrote: >> >>> Also note that for SPEC -funroll-loops helps GCC (yes ... we don't >>> enable that by default at -O3, we probably should). >> >> Richi, >> >> Are you suggesting enabling -funroll-loops by default at -O3? When I >> checked earlier this year, GCC was too aggressive with loop unrolling >> on non-numerically-intensive code and that option was not uniformly >> beneficial, unfortunately. It would be a good change if GCC's >> unrolling heuristics were better. > > yes, GCC's unroller behavior is at two extremes -- tree level full > unroller is too conservative, while rtl unroller is too aggressive > (e.g, in cases where ICC unroll 2 times, GCC unrolls by 9 -- even when > the body contains conditional branches and the trip count is a small > constant (e.g. 100). > > For comparison. ICC turns on loop unrolling at O3 -- but it does it > conservatively compared with GCC's behavior with -funroll-loops. Full > unrolling is turned on at O2 and above for all ICC, LLCM, and GCC, but > GCC's one is almost useless -- it does not allow any code growth at O2 > which means it only kicks in for tiny loops with very small trip > count. Both ICC and LLVM are more aggressive at O2.
I meant to enable the unroller at the GIMPLE level to the extent it is only with -funroll-loops. I agree the RTL level unroller is too aggressive. Richard. > David > >> >> Thanks, David
