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
>
