search for: loopdistribution

...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 loop d...

...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/discussi...

...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 fact...

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 arb...

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

Am Fr., 10. Jan. 2020 um 16:10 Uhr schrieb Renato Golin <rengolin at gmail.com>: > On Fri, 3 Jan 2020 at 11:27, Michael Kruse via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 1. Candidate selection through cost function > > -------------------------------------------- > > Instead of needing to know which transformation is profitable before > >

...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 a...

...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 LoopVersioning...

...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 LoopVe...

...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 su...

...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 LoopVe...

Am Sa., 11. Jan. 2020 um 07:43 Uhr schrieb Renato Golin <rengolin at gmail.com >: > On Sat, 11 Jan 2020 at 00:34, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Yes, as mentioned in the Q&A. Unfortunately VPlan is able to represent > > arbitrary code not has cheap copies. > > Orthogonal, but we should also be looking into implementing the cheap > copies

...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 >>&...

...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 LoopVersioning...

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 not...

...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 t...