Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-28 Thread Jeff Law
On 02/28/2016 02:11 PM, H.J. Lu wrote: On Sun, Feb 28, 2016 at 9:48 AM, H.J. Lu wrote: On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu wrote: On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law wrote: On 02/25/2016 03:00 AM, Richard Biener wrote: So I fail to see how only successor edges are relevant.

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-28 Thread H.J. Lu
On Sun, Feb 28, 2016 at 9:48 AM, H.J. Lu wrote: > On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu wrote: >> On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law 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 importan

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-28 Thread H.J. Lu
On Sat, Feb 27, 2016 at 3:59 PM, H.J. Lu wrote: > On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law 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

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-27 Thread H.J. Lu
On Thu, Feb 25, 2016 at 11:50 PM, Jeff Law 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 ha

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-26 Thread Richard Biener
On Fri, Feb 26, 2016 at 8:50 AM, Jeff Law 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 hav

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-25 Thread Jeff Law
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

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-25 Thread Jeff Law
On 02/25/2016 03:00 AM, Richard Biener wrote: + /* Look at BB's successors, if any are marked as BB_IRREDUCIBLE_LOOP, then + removing BB (and its outgoing edges) may make the loop a natural + loop. In which case we need to schedule loop fixups. */ + if (current_loops) +for (edge_

Re: [PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-25 Thread Richard Biener
On Thu, Feb 25, 2016 at 7:18 AM, Jeff Law wrote: > > PR69740 shows two instances where one or more transformations ultimately > lead to the removal of a basic block. > > In both cases, removal of the basic block removes a path into an irreducible > region and turns the irreducible region into a na

[PATCH] [RFA] [PR tree-optmization/69740] Schedule loop fixups when needed

2016-02-24 Thread Jeff Law
PR69740 shows two instances where one or more transformations ultimately lead to the removal of a basic block. In both cases, removal of the basic block removes a path into an irreducible region and turns the irreducible region into a natural loop. When that occurs we need to be requesting