search for: mergedloadstoremot

...add(createSimpleLoopUnrollPass(OptLevel)); // Unroll small loops I see -debug-pass=Structure output: Scalar Evolution Analysis Loop Pass Manager Induction Variable Simplification Recognize loop idioms Delete dead loops Unroll loops MergedLoadStoreMotion Which is in line to what I thought. However for this code snippet: if (EnableUnrollAndJam) { // Unroll and Jam. We do this before unroll but need to be in a separate // loop pass manager in order for the outer loop to be processed by // unroll and jam before the inner loop...

...gt; ./ObjCARC/ObjCARCOpts.cpp > >> ./ObjCARC/ProvenanceAnalysis.cpp > >> ./Scalar/DeadStoreElimination.cpp > >> ./Scalar/GVN.cpp > >> ./Scalar/LICM.cpp > >> ./Scalar/LoopVersioningLICM.cpp > >> ./Scalar/MemCpyOptimizer.cpp > >> ./Scalar/MergedLoadStoreMotion.cpp > >> ./Scalar/NewGVN.cpp > >> ./Utils/VNCoercion.cpp > >> > >> I glanced over all the uses in these files and I couldn't find any > >> usage that requires sizes to match. Actually most clients check > >> access sizes themselves. Most...

...sforms $ grep -Rl MustAlias . >> ./ObjCARC/ObjCARCOpts.cpp >> ./ObjCARC/ProvenanceAnalysis.cpp >> ./Scalar/DeadStoreElimination.cpp >> ./Scalar/GVN.cpp >> ./Scalar/LICM.cpp >> ./Scalar/LoopVersioningLICM.cpp >> ./Scalar/MemCpyOptimizer.cpp >> ./Scalar/MergedLoadStoreMotion.cpp >> ./Scalar/NewGVN.cpp >> ./Utils/VNCoercion.cpp >> >> I glanced over all the uses in these files and I couldn't find any usage >> that requires sizes to match. Actually most clients check access sizes >> themselves. Most don't need equal sizes, j...

...as : PartialAlias; I grepped for clients of MustAlias: ~/llvm/lib/Transforms $ grep -Rl MustAlias . ./ObjCARC/ObjCARCOpts.cpp ./ObjCARC/ProvenanceAnalysis.cpp ./Scalar/DeadStoreElimination.cpp ./Scalar/GVN.cpp ./Scalar/LICM.cpp ./Scalar/LoopVersioningLICM.cpp ./Scalar/MemCpyOptimizer.cpp ./Scalar/MergedLoadStoreMotion.cpp ./Scalar/NewGVN.cpp ./Utils/VNCoercion.cpp I glanced over all the uses in these files and I couldn't find any usage that requires sizes to match. Actually most clients check access sizes themselves. Most don't need equal sizes, just need one to be smaller than the other. BTW, B...

...pipeline and the code being run on. For example, the reproducer I reduced for this particular bug involved a situation where: 1. A pass had to preserve BasicAA 2. lcssa would make a change and thus only preserve a subset of passes (if it made no changes it would have preserved all) 2. then LICM and MergedLoadStoreMotion had to run and make no changes (and hence preserve all). 3. then GVN had to run and query BasicAA (presumably LICM or MergedLoadStoreMotion didn't make a query to BasicAA, or that query ended up not accessing the dangling TargetLibraryInfo). How should we solve this? I see two potential s...

...hich consists of three virtual functions: deleteValue(Value *V) copyValue(Value *From, Value *To) addEscapingUse(Use &U) These interfaces are *very* rarely called. Here are the only passes that ever bother to use these: - MemoryDependenceAnalysis.cpp - BasicBlockUtils.cpp - LoopSimplify.cpp - MergedLoadStoreMotion.cpp - GVN.cpp That's it. This is not a complete set of code that can delete a load or store, nor a complete list of things which can fold something into a Phi node or otherwise trigger an "escaping" use. Maybe these interfaces used to be much more widely used prior to the introduc...

...; ./ObjCARC/ProvenanceAnalysis.cpp >>>>> ./Scalar/DeadStoreElimination.cpp >>>>> ./Scalar/GVN.cpp >>>>> ./Scalar/LICM.cpp >>>>> ./Scalar/LoopVersioningLICM.cpp >>>>> ./Scalar/MemCpyOptimizer.cpp >>>>> ./Scalar/MergedLoadStoreMotion.cpp >>>>> ./Scalar/NewGVN.cpp >>>>> ./Utils/VNCoercion.cpp >>>>> >>>>> I glanced over all the uses in these files and I couldn't find any >>>>> usage that requires sizes to match. Actually most clients check >>...

...which passes you are thinking about here that do code > sinking/speculation that won't need it. > > Here's the list definitely needing it right now: > GVN > GVNHoist > LICM > LoadCombine > LoopReroll > LoopUnswitch > LoopVersioningLICM > MemCpyOptimizer > MergedLoadStoreMotion > Sink > > The list is almost certainly larger than this, this was a pretty trivial > grep and examination. > (and doesn't take into account bugs, etc) > > (Note, this list is stuff in the Scalar directory only. Everything in Vectorize would n eed it, etc) And in case...

> On Jul 21, 2016, at 7:45 AM, Philip Reames <listmail at philipreames.com> wrote: > > Joining in very late, but the tangent here has been interesting (if rather OT for the original thread). > > I agree with Danny that we might want to take a close look at how we model things like maythrow calls, no return, and other implicit control flow. I'm not convinced that moving

...IK, worse. They act as barriers to sinking *other things*. You cannot sink a store past a may-throw, or hoist a load above them. You can't optimize stores across them either: See: [PATCH] D21007: DSE: Don't remove stores made live by a call which unwinds. for the latter [llvm] r270828 - [MergedLoadStoreMotion] Don't transform across may-throw calls for the former. "It is unsafe to hoist a load before a function call which may throw, the throw might prevent a pointer dereference. Likewise, it is unsafe to sink a store after a call which may throw. The caller might be able to observe the dif...

...code >> sinking/speculation that won't need it. >> >> Here's the list definitely needing it right now: >> GVN >> GVNHoist >> LICM >> LoadCombine >> LoopReroll >> LoopUnswitch >> LoopVersioningLICM >> MemCpyOptimizer >> MergedLoadStoreMotion >> Sink >> >> The list is almost certainly larger than this, this was a pretty trivial >> grep and examination. >> (and doesn't take into account bugs, etc) >> >> > > (Note, this list is stuff in the Scalar directory only. Everything in > Ve...

I think it would make sense for (1) and (2). I am not sure if (3) is feasible in instcombine. (I am not too familiar with LoopInfo) For the Octasic's Opus platform, I modified shouldMergeGEPs in our fork to: if (GEP.hasAllZeroIndices() && !Src.hasAllZeroIndices() && !Src.hasOneUse()) return false; return Src.hasAllConstantIndices(); // was return false;

...; > Combine redundant instructions > Scalar Evolution Analysis > Canonicalize natural loops > Loop-Closed SSA Form Pass > Loop Pass Manager > Induction Variable Simplification > Recognize loop idioms > Delete dead loops > Unroll loops > Memory Dependence Analysis > MergedLoadStoreMotion > Dominator Tree Construction > Memory Dependence Analysis > Global Value Numbering > Memory Dependence Analysis > MemCpy Optimization > Sparse Conditional Constant Propagation > Dominator Tree Construction > Bit-Tracking Dead Code Elimination > Combine redundant instr...

Thank you all for your replies. So here seems to be an agreement that the documentation for PartialAlias is incorrect. Daniel: now you got me wondering about MustAlias. This is what the docs say: "The MustAlias response may only be returned if the two memory objects are *guaranteed to always start at exactly the same location*" This statement is regardless of the access sizes. For

...ue *To) > > addEscapingUse(Use &U) > > > > > > These interfaces are *very* rarely called. Here are the only passes > > that ever bother to use these: > > - MemoryDependenceAnalysis.cpp > > - BasicBlockUtils.cpp > > - LoopSimplify.cpp > > - MergedLoadStoreMotion.cpp > > - GVN.cpp > > > > > > That's it. This is not a complete set of code that can delete a > > load > > or store, nor a complete list of things which can fold something > > into a Phi node or otherwise trigger an "escaping" use. Maybe...

On Thu, Jul 14, 2016 at 4:48 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > Hi all, > > It looks like the key controversial point is the bit about the extra > control dependence on loads and stores[0]. Generally the consensus is > that (please chime if you think otherwise) it is not reasonable to > make the safety (or semantics) of a load instruction depend

...Form > Pass, Rotate Loops, Loop Invariant Code Motion, Unswitch loops, Combine > redundant instructions, Scalar Evolution Analysis, Canonicalize natural > loops, Loop-Closed SSA Form Pass, Induction Variable Simplification, > Recognize loop idioms, Delete dead loops, Unroll loops, > MergedLoadStoreMotion, Memory Dependence Analysis, Global Value Numbering, > MemCpy Optimization, Sparse Conditional Constant Propagation, Combine > redundant instructions, Jump Threading, Value Propagation, Dead Store > Elimination, Aggressive Dead Code Elimination, Simplify the CFG, Combine > redundant...

On Fri, Aug 14, 2015 at 3:35 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi Teresa, > > Thanks for layout down a detailed proposal on top of the slides, it is > very instructive and very pleasant to read. > Hi Mehdi, Thanks! > > I have a few questions, none of which touches the ELF aspect! :) > I apologize if you already addressed them and I missed it (if

...LVMX86AsmPrinter.a make[4]: Leaving directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Target/X86/InstPrinter' make[4]: Entering directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/lib/Target/X86/AsmParser' llvm[4]: Compiling X86AsmInstrumentation.cpp for Release+Asserts build llvm[3]: Compiling MergedLoadStoreMotion.cpp for Release+Asserts build llvm[3]: Compiling InstCombineSelect.cpp for Release+Asserts build llvm[3]: Compiling ErlangGCPrinter.cpp for Release+Asserts build llvm[3]: Compiling NaryReassociate.cpp for Release+Asserts build llvm[4]: Compiling X86AsmParser.cpp for Release+Asserts build llvm[3]...