On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law <l...@redhat.com> wrote:
> On 02/25/2016 03:00 AM, Richard Biener wrote:
>>
>>
>> So I fail to see how only successor edges are relevant. Isn't the
>> important
>> case to catch whether we remove an edge marked EDGE_IRREDUCIBLE_LOOP?
>> Even if the BB persists we might have exposed a new loop here.
>>
>> Note that it is not safe to look at {BB,EDGE}_IRREDUCIBLE_LOOP if the loop
>> state does not have LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS set
>> (the flags may be stale or missing). So it might be that we can't rely on
>> non-loop passes modifying the CFG to handle this optimistically.
>>
>> Thus, how about (my main point) moving this to remove_edge instead, like
>
> Yea. That works. The !loops_state_satisfies_p check will almost certainly
> cause us to trigger loop cleanups more often, but I think it's the
> right/safe thing to do to catch cases where we haven't go the
> IRREDUCIBLE_LOOP flags set.
>
>
> Bootstrapped and regression tested on x86_64-linux-gnu. OK for the trunk?
>
> Thanks,
> Jeff
>
>
> PR tree-optimization/69740
> * cfghooks.c (remove_edge): Request loop fixups if we delete
> an edge that might turn an irreducible loop into a natural
> loop.
>
> PR tree-optimization/69740
> * gcc.c-torture/compile/pr69740-1.c: New test.
> * gcc.c-torture/compile/pr69740-2.c: New test.
>
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69996
and may be other build failures in SPEC CPU 2006.
H.J.
