search for: d18762

...s which handles control flow and allows may-be-infinite loops to be removed under optional flag. Chandler suggested rather than a large change a series of small changes and, while that may not get us to small changes easily, there has been no further commentary on the diff: https://reviews.llvm.org/D18762. Given that, I will plan on proposing a series of diffs and would like to recruit some people who are interested in the change to help review those changes. I expect to stage as follows: 1. Rewrite base algorithm to introduce data structures needed to hold extra information (no functional c...

...rol flow and allows may-be-infinite loops to be removed under > optional flag. Chandler suggested rather than a large change a series of > small changes and, while that may not get us to small changes easily, there > has been no further commentary on the diff: > https://reviews.llvm.org/D18762. Given that, I will plan on proposing a > series of diffs and would like to recruit some people who are interested in > the change to help review those changes. > > > > I expect to stage as follows: > > > > 1. Rewrite base algorithm to introduce data structures ne...

I request additional review of diff: http://reviews.llvm.org/D18762 We noticed that a source of performance difference between llvm and gcc was in dead code elimination. This diff replaces ADCE with a new implementation which will remove control flow and, under option, also remove may-be-infinite loops which are dead. The patch current has "ADCE_new.h" a...

Hi, I have a new variant of Aggressive Dead Code Elimination that also removes dead branching. It is designed to minimize the cost of control-dependence analysis in the common case where almost the entire program is live. It also can optionally remove dead but may-be-infinite loops. When enabled for –O3 (replacing current ADCE pass) and removing loops, impact on SPEC2006 is in the noise but it