search for: bnwest

...p.603-625, September 2001. I have embedded the paper's pseudo code into comment blocks within the code. The algorithm finds reduction opportunities in both array accesses and explicit multiplications within loops. Next, I plan on writing the regression tests. thanks, Brian Brian West <bnwest <at> rice.edu> writes: > I am currently writing a new optimization pass for LLVM, based on the > paper Operator Strength Reduction (Taylor Simpson et al, 2001). I > noticed from the Developer Policy page that my code will need to be > reviewed before it is committed to the tru...

On Wed, Oct 27, 2010 at 1:29 PM, Brian West <bnwest at rice.edu> wrote: > Here is the patch for the new Operator Strength Reduction optimization > pass that I have written.  The bulk of the code is in > > lib/Transforms/Scalar/OperatorStrengthReduce.cpp > > The algorithm finds reduction opportunities in both array accesses and &...

On 10/27/10 8:34 PM, Eli Friedman wrote: > On Wed, Oct 27, 2010 at 1:29 PM, Brian West<bnwest at rice.edu> wrote: >> Here is the patch for the new Operator Strength Reduction optimization >> pass that I have written. The bulk of the code is in >> >> lib/Transforms/Scalar/OperatorStrengthReduce.cpp >> >> The algorithm finds reduction opportunities in...

On Thu, Oct 28, 2010 at 9:38 AM, Brian West <bnwest at rice.edu> wrote: >> 3. LLVM already has a significant amount of infrastructure for loop >> passes; why does this pass have its own code for finding loops? > > I saw the loop infrastructure for CFG loops. This algorithm finds loops in > the data flow (more precisely: stron...

Eli Friedman <eli.friedman <at> gmail.com> writes: > > Empirically the OSR optimization is compile-time faster than LSR. I have > > also noticed that OSR has more "analysis" requirements: Induction Variable > > User, Natural Loop Information, Canonicalize natural loops, and Scalar > > Evolution Analysis. Both OSR and LSR require the Dominator Tree

On Fri, Oct 29, 2010 at 11:18 AM, Brian West <bnwest at rice.edu> wrote: > Eli Friedman <eli.friedman <at> gmail.com> writes: >> >> > I did not mention in the original email (and should have) that OSR >> >> > needs >> >> > -instcombine to be run after it for cleanup. Also -licm, >>...

On Mon, Nov 15, 2010 at 10:38 AM, Brian West <bnwest at rice.edu> wrote: > On 11/13/10 11:05 PM, Daniel Berlin wrote: > > A big downside of the current LSR algorithm is it's slow. I had >> initially >> hoped that some of the heuristics would protect it better, but the problem >> is >> more complex than I ha...

On 11/13/10 11:05 PM, Daniel Berlin wrote: > > A big downside of the current LSR algorithm is it's slow. I had > initially > hoped that some of the heuristics would protect it better, but the > problem is > more complex than I had expected. I haven't done any measurements, > but it's likely that OSR is faster, which may interest some

Eli Friedman <eli.friedman <at> gmail.com> writes: > >> > I did not mention in the original email (and should have) that OSR needs > >> > -instcombine to be run after it for cleanup. Also -licm, -reassociate, -gvn > >> > and -sccp can be enabling optimizations for OSR. > >> > >> Hmm... perhaps that could be partially fixed

> > A big downside of the current LSR algorithm is it's slow. I had initially > hoped that some of the heuristics would protect it better, but the problem > is > more complex than I had expected. I haven't done any measurements, > but it's likely that OSR is faster, which may interest some people > regardless > of how the output compares. > A few years

I am currently writing a new optimization pass for LLVM, based on the paper Operator Strength Reduction (Taylor Simpson et al, 2001). I noticed from the Developer Policy page that my code will need to be reviewed before it is committed to the trunk. The Policy page also indicated that all "major" changes should to be announced before coding and should be done as a series of

Evan Cheng <evan.cheng <at> apple.com> writes: > Eli is right. We do need to see some benchmark numbers and understand how the pass will fit in the target > independent optimizer. While we encourage contribution, we typically don't commit new passes unless it > introduce new functionalities that have active clients. It would also help if you provide us with compile

On 10/29/10 1:26 PM, Eli Friedman wrote: > Sure, but you know which induction variables you created; you can just > zap the unused ones at the end of the pass, no? This is feasible. We would have to collect more information during OSR proper pass and add logic to cleanup at the end. >> FWIW I noticed that other optimizations (as seen in StandardPasses.h) are >> followed by