search for: loopsimplifycfg

...o, Quick question to see if I haven't missed anything: I would like convert counting down loops, i.e. loops with a constant -1 step value, to counting up loops, because the vectoriser is able to better deal with these loops (see e.g. D76838 that I was discussing today with Ayal). It looks like LoopSimplifyCFG and IndVarSimplify don't do this. So was just curious if I haven't missed anything here or in another pass I haven't yet considered. I was perhaps also expecting this to be the canonical form of loops, but couldn't find any evidence of that in [1] or in source-code. The obvious foll...

On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames <listmail at philipreames.com> wrote: > There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate > with other loop passes) and eliminates trivial branches. Having a simple > pass which just strips unreachable blocks and converts conditional branches > to unconditional ones while updating appropriate analyzes (LoopInfo, > DomTree, LCSSA, e...

...On Nov 29, 2017, at 1:08 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate with other loop passes) and eliminates trivial branches. Having a simple pass which just strips unreachable blocks and converts conditional branches to unconditional ones while updating appropriate analyzes (LoopInfo, DomTree, LCSSA, etc..) seems very rea...

Hi Davide, > On Nov 29, 2017, at 1:08 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Nov 29, 2017 at 9:48 AM, Philip Reames > <listmail at philipreames.com> wrote: >> There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate >> with other loop passes) and eliminates trivial branches. Having a simple >> pass which just strips unreachable blocks and converts conditional branches >> to unconditional ones while updating appropriate analyzes (LoopInfo, >> D...

There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate with other loop passes) and eliminates trivial branches.  Having a simple pass which just strips unreachable blocks and converts conditional branches to unconditional ones while updating appropriate analyzes (LoopInfo, DomTree, LCSSA, etc..) seems very...

...ion to see if I haven't missed anything: I would like convert > counting down loops, i.e. loops with a constant -1 step value, to counting up > loops, because the vectoriser is able to better deal with these loops (see e.g. > D76838 that I was discussing today with Ayal). It looks like LoopSimplifyCFG > and IndVarSimplify don't do this. So was just curious if I haven't missed > anything here or in another pass I haven't yet considered. I was perhaps also > expecting this to be the canonical form of loops, but couldn't find any > evidence of that in [1] or in source-co...

...engthenNoWrapFlags` after `GroupByComplexity`; 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....

...; 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. +...

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

...ode provides the basic functionality and tries be ‘API-equivalent’ with the current DomTree implementation. The NewDomTree is also able to convert itself to the current one for testing and verification purposes. Dynamic dominators are hacked into 3 existing passes (DomTreeWrapperPass, LoopDeletion, LoopSimplifyCFG) to test correctness and experiment with the use of the new API. The prototype also comes with a bunch of testing utilities and a simple benchmarking tool. *4. Performance* The real life performance of full dynamic DBS-based DomTree recalculation is between 20% and 2% better on a machine with tw...

...r "LoopStandard" analyses. >> > > Is this implemented - do the loop passes preserve BPI? > > Nope, not implemented right now. > One of the problems is that even loop canonicalization passes run at the > start of loop pass manager dont preserve it > (and at least LoopSimplifyCFG does change control flow). > > > In buildFunctionSimplificationPipeline (where LoopFullUnrollPass is added > as in the sketch), LateLoopOptimizationsEPCallbacks > and LoopOptimizerEndEPCallbacks seem to allow some arbitrary loop passes to > be inserted into the pipelines (via flag...

...t; >> >> Is this implemented - do the loop passes preserve BPI? > Nope, not implemented right now. > One of the problems is that even loop canonicalization passes > run at the start of loop pass manager dont preserve it > (and at least LoopSimplifyCFG does change control flow). >> >> In buildFunctionSimplificationPipeline >> (where LoopFullUnrollPass is added as in the sketch), >> LateLoopOptimizationsEPCallbacks >> and LoopOptimizerEndEPCallbacks seem to allow some arbitrary >>...

...tries be ‘API-equivalent’ > > with the current DomTree implementation. The NewDomTree is also able to > > convert itself to the current one for testing and verification purposes. > > Dynamic dominators are hacked into 3 existing passes (DomTreeWrapperPass, > > LoopDeletion, LoopSimplifyCFG) to test correctness and experiment with > > the > > use of the new API. > > > > The prototype also comes with a bunch of testing utilities and a simple > > benchmarking tool. > > > > *4. Performance* > > > > The real life performance of full dy...

> I'm not necessarily sympathetic to the idea of adding another canonicalization pass only for this purpose. The problem is that as you said, SimplifyCfg does all sorts of stuff, and I suspect is not the fastest pass in the world. Also, in the case that annoys me, there is an LCSSA pass in the middle, and I suspect it would be a better idea to only do the LCSSA etc. transform again if no

...this implemented - do the loop passes preserve BPI? >> Nope, not implemented right now. >> One of the problems is that even loop canonicalization >> passes run at the start of loop pass manager dont preserve it >> (and at least LoopSimplifyCFG does change control flow). >>> >>> In buildFunctionSimplificationPipeline >>> (where LoopFullUnrollPass is added as in the sketch), >>> LateLoopOptimizationsEPCallbacks >>> and LoopOptimizerEndEPCallbacks s...

...gt; Nope, not implemented right now. >>> One of the problems is that even loop >>> canonicalization passes run at the start of loop >>> pass manager dont preserve it >>> (and at least LoopSimplifyCFG does change control flow). >>>> >>>> In buildFunctionSimplificationPipeline >>>> (where LoopFullUnrollPass is added as in the >>>> sketch), LateLoopOptimizationsEPCallbacks >>>>...

Here's a sketch of the proposed approach for just one pass (but imagine more) https://reviews.llvm.org/D58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo

Hi, This is Ariel from the Rust team again. I am having another pass ordering issue. Looking at the pass manager at https://github.com/llvm-mirror/llvm/blob/7034870f30320d6fbc74effff539d946018cd00a/lib/Transforms/IPO/PassManagerBuilder.cpp (the early SimplifyCfg now doesn't sink stores anymore! I can't wait until I can get to use that in rustc!) I find that the loop optimization group