search for: loopdistribut

...o DA frameworks at the moment. The file you mention is > only used currently by the LoopInterchange pass that is off by default. > There is also the other framework that I’ve been working on called > LoopAccessAnalysis that’s currently used by the LoopVectorizer, > LoopLoadElimination, LoopDistribution and LICMLoopVersioning (the latter > two are off by default). > Do you think it is reasonable and feasible to provide a common interface for different loop dependence analyses like alias analysis, such that passes like LoopVectorizer/LoopLoadElimination/LoopDistribution etc. can query loo...

...We actually have two DA frameworks at the moment. The file you mention is only used currently by the LoopInterchange pass that is off by default. There is also the other framework that I’ve been working on called LoopAccessAnalysis that’s currently used by the LoopVectorizer, LoopLoadElimination, LoopDistribution and LICMLoopVersioning (the latter two are off by default). >> >> Value range propagation pass. There was a discussion about this topic (https://groups.google.com/forum/#!topic/llvm-dev/XXqfemtDX74/discussion <https://groups.google.com/forum/#%21topic/llvm-dev/XXqfemtDX74/discu...

...pendences between > instructions in L2 to instructions in L1 which would be illegal. > > As a side effect you’d also get the total set of memchecks which you could > filter to only include checks where the participating pointers come from > different loops. (This is quite similar to LoopDistribution.) > I am happy to add a routine in a subsequent patch that filter the checks. > > Also I don’t think it should be too hard to teach LVer to be able to > version two consecutive loops (or arbitrary CFG?). > I think yes. Instead of Loop Versioning deciding to version, code can be f...

Hi all, I have created a patch (up for review at: http://reviews.llvm.org/D17386) that does Loop Fusion implementation. Approach: Legality: Currently it can fuse two adjacent loops whose iteration spaces are same and are at same depth. Dependence legality: Currently, dependence legality cannot be checked across loops. Hence the loops are cloned along a versioned path, unconditionally fused

...ve backward dependences between instructions in L2 to instructions in L1 which would be illegal. > > As a side effect you’d also get the total set of memchecks which you could filter to only include checks where the participating pointers come from different loops. (This is quite similar to LoopDistribution.) > I am happy to add a routine in a subsequent patch that filter the checks. > Just to clarify, I meant to filter the runtime checks which is currently not done in the patch. > > Also I don’t think it should be too hard to teach LVer to be able to version two consecutive loops (or...

Hi Adam, I'm looking into your LLE pass in order to remove the RAR dependency from GVN, and I've hit a problem that might need some more thinking. I've modified your patch to cope with both kinds of dependencies in the ForwardingCandidate class, but the way the pass gathers informations only brings RAW dependencies: const auto *Deps = LAI.getDepChecker().getDependences(); if

...on > > fails, the original code is executed. > > This sounds like it will bloat code for a lot of cold cases. Or worse, > get it wrong, and put hot code in the cold path. Are you arguing against code versioning? It is already done today by multiple passes such as LoopVersioningLICM, LoopDistribute, LoopUnrollAndJam and LoopVectorize. The proposal explicitly tries to avoid code bloat by having just one fallback copy. Runtime conditions can be chosen more or less optimistically, but I don't see how this should be an argument for all kinds of versioning. If you are concerned about bloat i...

...improve and generalize the required analyses >>>> (e.g. the LoopVectorizer’s dependence analysis + loop >>>> versioning analysis into a stand-alone analysis pass >>>> (LoopAccessAnalysis)) and then build new transformations (e.g. >>>> LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on >>>> top of these. >>>> >>>> The idea was that infrastructure would be incrementally >>>> improved from two directions: >>>> >>>> - As new transformations are buil...

...r more-or-less established direction was so far to incrementally improve > and generalize the required analyses (e.g. the LoopVectorizer’s dependence > analysis + loop versioning analysis into a stand-alone analysis pass > (LoopAccessAnalysis)) and then build new transformations (e.g. > LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. > > The idea was that infrastructure would be incrementally improved from two > directions: > > - As new transformations are built analyses have to be improved (e.g. past > improvements to LAA to support the LoopVersion...

...re-or-less established direction was so far to incrementally > improve and generalize the required analyses (e.g. the > LoopVectorizer’s dependence analysis + loop versioning analysis into a > stand-alone analysis pass (LoopAccessAnalysis)) and then build new > transformations (e.g. LoopDistribution, LoopLoadElimination, > LICMLoopVersioning) on top of these. > > The idea was that infrastructure would be incrementally improved from > two directions: > > - As new transformations are built analyses have to be improved (e.g. > past improvements to LAA to support the Loo...

...stablished direction was so far to incrementally >> improve and generalize the required analyses (e.g. the LoopVectorizer’s >> dependence analysis + loop versioning analysis into a stand-alone analysis >> pass (LoopAccessAnalysis)) and then build new transformations (e.g. >> LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. >> >> The idea was that infrastructure would be incrementally improved from two >> directions: >> >> - As new transformations are built analyses have to be improved (e.g. >> past improvements to LAA to...

...ired analyses >>>>> (e.g. the LoopVectorizer’s dependence analysis + loop >>>>> versioning analysis into a stand-alone analysis pass >>>>> (LoopAccessAnalysis)) and then build new transformations >>>>> (e.g. LoopDistribution, LoopLoadElimination, >>>>> LICMLoopVersioning) on top of these. >>>>> >>>>> The idea was that infrastructure would be incrementally >>>>> improved from two directions: >>>>> >>>>>...

...gt;> >> Our more-or-less established direction was so far to incrementally improve and generalize the required analyses (e.g. the LoopVectorizer’s dependence analysis + loop versioning analysis into a stand-alone analysis pass (LoopAccessAnalysis)) and then build new transformations (e.g. LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. >> >> The idea was that infrastructure would be incrementally improved from two directions: >> >> - As new transformations are built analyses have to be improved (e.g. past improvements to LAA to support the Loo...

...R will invariably create > some adoption barriers. I see it as an advantage in respect of adoption: It can be switched on and off without affecting other parts. > > Are you arguing against code versioning? It is already done today by > > multiple passes such as LoopVersioningLICM, LoopDistribute, > > LoopUnrollAndJam and LoopVectorize. The proposal explicitly tries to > > avoid code bloat by having just one fallback copy. Runtime conditions > > can be chosen more or less optimistically, but I don't see how this > > should be an argument for all kinds of version...

...was so far to incrementally >>> improve and generalize the required analyses (e.g. the >>> LoopVectorizer’s dependence analysis + loop versioning analysis into >>> a stand-alone analysis pass (LoopAccessAnalysis)) and then build new >>> transformations (e.g. LoopDistribution, LoopLoadElimination, >>> LICMLoopVersioning) on top of these. >>> >>> The idea was that infrastructure would be incrementally improved >>> from two directions: >>> >>> - As new transformations are built analyses have to be improved >&g...

...r more-or-less established direction was so far to incrementally improve > and generalize the required analyses (e.g. the LoopVectorizer’s dependence > analysis + loop versioning analysis into a stand-alone analysis pass > (LoopAccessAnalysis)) and then build new transformations (e.g. > LoopDistribution, LoopLoadElimination, LICMLoopVersioning) on top of these. > > The idea was that infrastructure would be incrementally improved from two > directions: > > - As new transformations are built analyses have to be improved (e.g. past > improvements to LAA to support the LoopVersion...

On 03/20/2016 05:38 AM, Aries Gunawan via llvm-dev wrote: > > Hi everyone, > > I am very interested in contributing to LLVM project in this year’s > GSoC. I am new with LLVM, but this is used in the compiler course in > my university. So, I am thinking to involve in LLVM development to > have a better knowledge of the system. Currently, I am preparing the > proposal.

Hi everyone, I am very interested in contributing to LLVM project in this year's GSoC. I am new with LLVM, but this is used in the compiler course in my university. So, I am thinking to involve in LLVM development to have a better knowledge of the system. Currently, I am preparing the proposal. One of the project that caught my eyes is "New Transformations and Analysis". Several

...ariant using a cost function and select the 'best' when re-generating LLVM-IR again (or re-use the original LLVM-IR). Otherwise, each transformation will have to implement its own profitability heuristic but cannot know what other passes will do. For instance, the motivation for LLVM's LoopDistribution is to enable vectorization of loops that can be separated from other loops. However, it does not know whether LoopVectorize will actually vectorize the loop, or whether two vectorizable loops are better vectorized together. Instantiating every possible sequence of transformations of course is n...

...to incrementally > >>>improve and generalize the required analyses (e.g. the > >>>LoopVectorizer’s dependence analysis + loop versioning analysis into a > >>>stand-alone analysis pass (LoopAccessAnalysis)) and then build new > >>>transformations (e.g. LoopDistribution, LoopLoadElimination, > >>>LICMLoopVersioning) on top of these. > >>> > >>>The idea was that infrastructure would be incrementally improved from > >>>two directions: > >>> > >>>- As new transformations are built analyses hav...