similar to: [LLVMdev] Landing my new development on the trunk ...

Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] Landing my new development on the trunk ..."

2010 Oct 27
2
[LLVMdev] Landing my new development on the trunk ...
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 optimization is based on the algorithm described within the paper that can be found here: http://portal.acm.org/citation.cfm?id=504709.504710 Keith D. Cooper , L. Taylor Simpson , Christopher A. Vick, Operator strength
2010 Oct 29
0
[LLVMdev] Landing my new development on the trunk ...
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, >> >> > -reassociate, -gvn >>
2010 Oct 28
0
[LLVMdev] Landing my new development on the trunk ...
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 > explicit multiplications within loops.
2010 Nov 16
1
[LLVMdev] Landing my new development on the trunk ...
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 had expected. I haven't done any
2010 Oct 28
3
[LLVMdev] Landing my new development on the trunk ...
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
2010 Oct 29
2
[LLVMdev] Landing my new development on the trunk ...
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
2010 Oct 29
0
[LLVMdev] Landing my new development on the trunk ...
On Oct 29, 2010, at 12:20 PM, Brian West wrote: > 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
2010 Nov 15
0
[LLVMdev] Landing my new development on the trunk ...
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
2010 Oct 28
0
[LLVMdev] Landing my new development on the trunk ...
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: strongly-connected components in the >
2010 Oct 28
1
[LLVMdev] Landing my new development on the trunk ...
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
2010 Oct 29
3
[LLVMdev] Landing my new development on the trunk ...
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
2010 Nov 11
0
[LLVMdev] Landing my new development on the trunk ...
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
2010 Nov 14
2
[LLVMdev] Landing my new development on the trunk ...
> > 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
2019 Dec 19
2
Flang landing in the monorepo
On 18/12/2019 21:49, Eric Christopher wrote: > Yes, I looked through those sources and a number of my questions > around which clang versions have been supported and directory > structure. I think the only difference is removing the direct > questions about earlier flang, but I still don't see code generation > or uses of llvm libraries that would conform to "written in
2011 Jul 08
0
[LLVMdev] type-system-rewrite branch near landing
> 1. Clang - Jay, do you have a patch for this?  Can you create a branch of the clang repo or send an updated version of the patch to the list? I've created a clang type-system-rewrite branch and committed all my purely mechanical changes: de-constifying llvm::Types as necessary, and using the new llvm::StructType::createNamed/setBody to create the "implicit" structs used by
2006 Nov 01
1
did my searching but still couldn't find anything for bayesian dlm
I familarized myelf with kalmanlike and structts which are approaches for building and estimating ( and forecasting ) state space models ( or the equivalent arima models ). back in 2003, gavin simpson wrote an email describing the west and harrison apprach to estimate state space models and asked if anything was out there for using that approach. the goals of this approach are the same as kalman
2011 Jul 09
2
[LLVMdev] type-system-rewrite branch landing tomorrow
2011/7/9 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >> It looks like we need to have opaque function types? Or we need to defer >> emission of some types until we've finished the translation unit. > > We were deferring this before, no? We could not produce a function type > taking an opaque type. Once it go resolved we would need to revisit the >
2011 Jul 09
0
[LLVMdev] type-system-rewrite branch landing tomorrow
I'm sorry, I've been away from the computer. I'll investigate this in the next half hour. Thanks for the test cases! -Chris On Jul 9, 2011, at 3:27 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 2011/7/9 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>: >>> It looks like we need to have opaque function types? Or we need to defer >>>
2009 Sep 09
2
"predict"-fuction for metaMDS (vegan)
Dear r-Community, Step1: I would like to calculate a NMDS (package vegan, function metaMDS) with species data. Step2: Then I want to plot environmental variables over it, using function envfit. The Problem: One of these environmental variables is cos(EXPOSURE). But for flat releves there is no exposure. The value is missing and I can't call it 0 as 0 stands for east and west. Therefore I
2018 May 10
2
LLVM SCEV isAddRecNeverPoison and strength reduction
+CC llvm-dev On Tue, May 8, 2018 at 2:34 AM, Gal Zohar <Gal.Zohar at ceva-dsp.com> wrote: > I noticed that SCEV, when trying to perform strength reduction, doesn’t use > the ability to prove an induction variable does not signed/unsigned wrap due > to infinite loops. > > Is there an easy way to use the isAddRecNeverPoison function when > determining if strength reduction