search for: looploadelimin

Thank you, Adam. It passes all the benchmarks I have. Haicheng From: anemet at apple.com [mailto:anemet at apple.com] Sent: Wednesday, March 09, 2016 7:17 PM To: Haicheng Wu; Eric Christopher; Benjamin Kramer Cc: llvm-dev Subject: Re: Regression in SPEC2006/gcc caused by LoopLoadElimination I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys please give it a test with your codebase. (You need to enable the pass with -mllvm -enable-loop-load-elim.) Thanks! Adam On Mar 7, 2016, at 11:05 PM, Adam Nemet <anemet at apple.com <mailto:anemet at...

Hi Adam, I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong result (166.s) in AArch64 when running with *ref* data set. The error happens when I use either "-Ofast -flto -fuse-ld=gold" or "-O3 -fno-strict-aliasing". Please let me know if you need more information. Best, Haicheng...

.... Should be able to make progress from here without further help from you. Adam > Thanks, > Adam > >> On Mar 7, 2016, at 8:33 AM, Haicheng Wu <haicheng at codeaurora.org <mailto:haicheng at codeaurora.org>> wrote: >> >> Hi Adam, >> >> I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong result (166.s) in AArch64 when running with *ref* data set. The error happens when I use either “-Ofast -flto -fuse-ld=gold” or “-O3 -fno-strict-aliasing”. Please let me know if you need more information. >> >> Best, >> >&...

...gt; > OK, I managed to reproduce this locally. Should be able to make progress > from here without further help from you. > > Adam > > Thanks, > Adam > > On Mar 7, 2016, at 8:33 AM, Haicheng Wu <haicheng at codeaurora.org> wrote: > > Hi Adam, > > I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong > result (166.s) in AArch64 when running with *ref* data set. The error > happens when I use either “-Ofast -flto -fuse-ld=gold” or “-O3 > -fno-strict-aliasing”. Please let me know if you need more information. > > Best, > > H...

....org> > To: "Daniel Berlin" <dberlin at dberlin.org> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Monday, November 2, 2015 1:16:18 PM > Subject: Re: [llvm-dev] Prefixing DEBUG messages with DEBUG_TYPE (was re: [PATCH] D13259: LLE 6/6: Add > LoopLoadElimination pass) > > To ask a basic question first: Why do we need prefixes at all? Are > the messages that likely to be confused? As far as I understand this > case it was only mentioned because of inconsistent prefix/no-prefix > use, there was no indication that we should actually have...

...; t <<":" << x;) #define DEBUG_MSG(x) DEBUG_MSG_WITH_TYPE(DEBUG_TYPE, x) Suggestions, however, welcome! ---------- Forwarded message ---------- From: Renato Golin <renato.golin at linaro.org> Date: Fri, Oct 30, 2015 at 10:15 AM Subject: Re: [PATCH] D13259: LLE 6/6: Add LoopLoadElimination pass To: anemet at apple.com, hfinkel at anl.gov, dberlin at dberlin.org Cc: mssimpso at codeaurora.org, sanjoy at playingwithpointers.com, llvm-commits at lists.llvm.org rengolin added a comment. In http://reviews.llvm.org/D13259#278362, @dberlin wrote: > I would suggest rather than pr...

...NFCI. +4% 9. r250157: [GlobalsAA] Turn GlobalsAA on again by default. +1% 10. r251049: [SCEV] Mark AddExprs as nsw or nuw if legal. +23% 11. No data 12. r259252: AttributeSetImpl: Summarize existing function attributes in a bitset. -1% r259256: Add LoopSimplifyCFG pass. -2% 13. r262250: Enable LoopLoadElimination by default. +3% 14. r262839: Revert "Enable LoopLoadElimination by default". -3% 15. r263393: Remove PreserveNames template parameter from IRBuilder. -3% 16. r263595: Turn LoopLoadElimination on again. +3% 17. r267672: [LoopDist] Add llvm.loop.distribute.enable loop metadata. +4% 18....

...lts*&, llvm::DominatorTree*&, llvm::LoopInfo*&) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/unique_ptr.h:821:34 llvm::LoopAccessLegacyAnalysis::getInfo(llvm::Loop*) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:2275:5 (anonymous namespace)::LoopLoadElimination::runOnFunction(llvm::Function&)::'lambda'(llvm::Loop&)::operator()(llvm::Loop&) const $SRC/llvm-project/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp:651:53 llvm::LoopAccessInfo const& llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>::cal...

...propriate scope. \ 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-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). > 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/LoopDistributio...

...lsAA on again by default. +1% >> 10. r251049: [SCEV] Mark AddExprs as nsw or nuw if legal. +23% >> 11. No data >> 12. r259252: AttributeSetImpl: Summarize existing function attributes in a bitset. -1% >> r259256: Add LoopSimplifyCFG pass. -2% >> 13. r262250: Enable LoopLoadElimination by default. +3% >> 14. r262839: Revert "Enable LoopLoadElimination by default". -3% >> 15. r263393: Remove PreserveNames template parameter from IRBuilder. -3% >> 16. r263595: Turn LoopLoadElimination on again. +3% >> 17. r267672: [LoopDist] Add llvm.loop.dist...

...gain by default. +1% > > 10. r251049: [SCEV] Mark AddExprs as nsw or nuw if legal. +23% > > 11. No data > > 12. r259252: AttributeSetImpl: Summarize existing function attributes in > a bitset. -1% > > r259256: Add LoopSimplifyCFG pass. -2% > > 13. r262250: Enable LoopLoadElimination by default. +3% > > 14. r262839: Revert "Enable LoopLoadElimination by default". -3% > > 15. r263393: Remove PreserveNames template parameter from IRBuilder. -3% > > 16. r263595: Turn LoopLoadElimination on again. +3% > > 17. r267672: [LoopDist] Add llvm.loop....

...lts*&, llvm::DominatorTree*&, llvm::LoopInfo*&) /usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/unique_ptr.h:821:34 llvm::LoopAccessLegacyAnalysis::getInfo(llvm::Loop*) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:2275:5 (anonymous namespace)::LoopLoadElimination::runOnFunction(llvm::Function&)::'lambda'(llvm::Loop&)::operator()(llvm::Loop&) const $SRC/llvm-project/llvm/lib/Transforms/Scalar/LoopLoadElimination.cpp:651:53 llvm::LoopAccessInfo const& llvm::function_ref<llvm::LoopAccessInfo const& (llvm::Loop&)>::cal...

...ou the wrong answer. If i disable all of phitransaddr's fun magic, your testcase starts working. I'll be honest, i don't have the energy ATM to track down what fun safety condition it's missing here. I'd actually rather disable the code (which is a mess) and focus on improving looploadelimination. Maybe someone else wants to take a look at it. (I'll add all this to the bug) --Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/551f2f7f/attachment.html>

...other reason it could give different answers after running a bunch of passes is the random scanning limits it has. On the PRE side: PHITranslateAddr goes through a bunch of crazy machinations to try to be able to prove things about inter-iteration variables instead of just doing phi translation. LoopLoadElimination was written so that these could be removed, because they are pretty much crazytown. --Dan On Fri, Jan 13, 2017 at 10:31 AM, Friedman, Eli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/13/2017 12:31 AM, Mikael Holmén via llvm-dev wrote: > >> Hi, >> >&...

This is a pretty nice warning. Should we enable it for LLVM's build when the host compiler supports it? Benjamin Kramer via llvm-commits <llvm-commits at lists.llvm.org> writes: > Author: d0k > Date: Mon Feb 22 07:11:58 2016 > New Revision: 261524 > > URL: http://llvm.org/viewvc/llvm-project?rev=261524&view=rev > Log: > Fix some abuse of auto flagged by

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

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

...ablished 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 utility, future...