On Mon, Sep 17, 2012 at 12:52 PM, Eric Botcazou 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 --param max-
> compl
> 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. Comp
On Thu, Sep 13, 2012 at 4:00 PM, Eric Botcazou 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
>> thought the real
> 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-ran
On Thu, Sep 13, 2012 at 3:11 PM, Eric Botcazou 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 that they will be
>
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 o
