mirror of
https://github.com/RPCS3/llvm.git
synced 2025-01-02 09:49:09 +00:00
7c422ac216
memcpy, memset and other intrinsics that only access their arguments to be readnone if the intrinsic's arguments all point to local memory. This improves the testcase in the README to readonly, but it could in theory be made readnone, however this would involve more sophisticated analysis that looks through the memcpy. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@92829 91177308-0d34-0410-b5e6-96231b3b80d8 |
||
|---|---|---|
| .. | ||
| IPA | ||
| AliasAnalysis.cpp | ||
| AliasAnalysisCounter.cpp | ||
| AliasAnalysisEvaluator.cpp | ||
| AliasDebugger.cpp | ||
| AliasSetTracker.cpp | ||
| Analysis.cpp | ||
| BasicAliasAnalysis.cpp | ||
| CaptureTracking.cpp | ||
| CFGPrinter.cpp | ||
| CMakeLists.txt | ||
| ConstantFolding.cpp | ||
| DbgInfoPrinter.cpp | ||
| DebugInfo.cpp | ||
| DomPrinter.cpp | ||
| InlineCost.cpp | ||
| InstCount.cpp | ||
| InstructionSimplify.cpp | ||
| Interval.cpp | ||
| IntervalPartition.cpp | ||
| IVUsers.cpp | ||
| LazyValueInfo.cpp | ||
| LibCallAliasAnalysis.cpp | ||
| LibCallSemantics.cpp | ||
| LiveValues.cpp | ||
| LoopDependenceAnalysis.cpp | ||
| LoopInfo.cpp | ||
| LoopPass.cpp | ||
| Makefile | ||
| MemoryBuiltins.cpp | ||
| MemoryDependenceAnalysis.cpp | ||
| PHITransAddr.cpp | ||
| PointerTracking.cpp | ||
| PostDominators.cpp | ||
| ProfileEstimatorPass.cpp | ||
| ProfileInfo.cpp | ||
| ProfileInfoLoader.cpp | ||
| ProfileInfoLoaderPass.cpp | ||
| ProfileVerifierPass.cpp | ||
| README.txt | ||
| ScalarEvolution.cpp | ||
| ScalarEvolutionAliasAnalysis.cpp | ||
| ScalarEvolutionExpander.cpp | ||
| SparsePropagation.cpp | ||
| Trace.cpp | ||
| ValueTracking.cpp | ||
Analysis Opportunities:
//===---------------------------------------------------------------------===//
In test/Transforms/LoopStrengthReduce/quadradic-exit-value.ll, the
ScalarEvolution expression for %r is this:
{1,+,3,+,2}<loop>
Outside the loop, this could be evaluated simply as (%n * %n), however
ScalarEvolution currently evaluates it as
(-2 + (2 * (trunc i65 (((zext i64 (-2 + %n) to i65) * (zext i64 (-1 + %n) to i65)) /u 2) to i64)) + (3 * %n))
In addition to being much more complicated, it involves i65 arithmetic,
which is very inefficient when expanded into code.
//===---------------------------------------------------------------------===//