Yes - now cfg_cleanup does that (and it really shouldn't be its job). That
was the improvement I talked about - reducing the number of BBs a lot.
OK, I removed the code and compiled the testcase of PR 43186 with --param max-
completely-peel-loop-nest-depth=32 and got back the explosion.
On Mon, Sep 17, 2012 at 12:52 PM, Eric Botcazou ebotca...@adacore.com wrote:
Yes - now cfg_cleanup does that (and it really shouldn't be its job). That
was the improvement I talked about - reducing the number of BBs a lot.
OK, I removed the code and compiled the testcase of PR 43186 with
Hi,
the attached testcase triggers a memory exhaustion at -O2 during the cunrolli
pass on the mainline and 4.7 branch. The problem is that the size estimates
disregard induction variable computations on the ground that they will be
folded later. But they aren't folded between the iterations
On Thu, Sep 13, 2012 at 3:11 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
the attached testcase triggers a memory exhaustion at -O2 during the cunrolli
pass on the mainline and 4.7 branch. The problem is that the size estimates
disregard induction variable computations on the ground
Indeed somewhat simple-minded - when originally fixing a similar testcase
(heh ...) I improved things by improving CFG cleanup to fold some more
conditions by looking at SSA defs, that improved things a lot. I also
thought the real fix should involve some scalar optimization on a
sub-range
On Thu, Sep 13, 2012 at 4:00 PM, Eric Botcazou ebotca...@adacore.com wrote:
Indeed somewhat simple-minded - when originally fixing a similar testcase
(heh ...) I improved things by improving CFG cleanup to fold some more
conditions by looking at SSA defs, that improved things a lot. I also
