> On Sun, 18 Nov 2012, Jan Hubicka wrote: > > > > > this patch reduces max-peeled-insns and max-completely-peeled-insns > > > > > from 400 > > > > > to 100. The reason why I am doing this is that I want to reduce code > > > > > bloat > > > > > caused by my cunroll work that enabled a lot more unrolling then > > > > > previously > > > > > causing considerable code size regression at -O3. > > > > > > > > Did you notice that gcc.c-torture/compile/pr43186.c regressed? It now > > > > again > > > > takes a while to compile, so times out on slow machines: > > > > > > I did not :(. I am currently on a trip, but will take a look on tuesday. > > > If it seems to disturb testing, please just revert the patch for time > > > being. > > > > OK, here are multiple issues. > > 1) recursive inlining makes huge loop nest (of 18 loops) > > 2) SCEV is very slow on answering simple_iv tests in this case becuase it > > walks > > the nest > > 3) unroller is computing loop body size even when it is clear the body is > > much larger > > than the limit (the outer loop has 78000 instructions) > > > > I will prepare patches to fix those issues. > > The recent (well, a week ago) params.def change also regressed > gfortran.dg/reassoc_4.f almost everywhere; see PR55452. > > I guess a fix is fairly trivial, I just don't know to what.
Yes, we siply should add explicit unrolling limits there, I believe I posted a patch? I am currently on a way, I will look up the message and/or post it. Honza > > brgds, H-P
