summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
* Fix "the the" in comments.Eric Christopher2015-06-192-2/+2
| | | | llvm-svn: 240112
* [NFC] more comments in SLSRJingyue Wu2015-06-181-0/+9
| | | | llvm-svn: 239984
* [PM/AA] Remove the UnknownSize static member from AliasAnalysis.Chandler Carruth2015-06-172-7/+7
| | | | | | | | This is now living in MemoryLocation, which is what it pertains to. It is also an enum there rather than a static data member which is left never defined. llvm-svn: 239886
* [PM/AA] Remove the Location typedef from the AliasAnalysis class nowChandler Carruth2015-06-175-43/+40
| | | | | | | | | | | | that it is its own entity in the form of MemoryLocation, and update all the callers. This is an entirely mechanical change. References to "Location" within AA subclases become "MemoryLocation", and elsewhere "AliasAnalysis::Location" becomes "MemoryLocation". Hope that helps out-of-tree folks update. llvm-svn: 239885
* Rename Reduction variables/structures to Recurrence.Tyler Nowicki2015-06-161-4/+4
| | | | | | | | A reduction is a special kind of recurrence. In the loop vectorizer we currently identify basic reductions. Future patches will extend this to identifying basic recurrences. llvm-svn: 239835
* Move logic from JumpThreading into LazyValue info to simplify caller. Philip Reames2015-06-161-51/+17
| | | | | | | | This change is hopefully NFC. The only tricky part is that I changed the context instruction being used to the branch rather than the comparison. I believe both to be correct, but the branch is strictly more powerful. With the moved code, using the branch instruction is required for the basic block comparison test to return the same result. The previous code was able to directly access both the branch and the comparison where the revised code is not. Differential Revision: http://reviews.llvm.org/D9652 llvm-svn: 239797
* [Statepoints] Skip a vector copy when uniquing values.Benjamin Kramer2015-06-131-11/+4
| | | | | | No functionality change intended. llvm-svn: 239688
* Revert 239644.Matt Wala2015-06-131-3/+1
| | | | llvm-svn: 239650
* [Scalarizer] Fix potential for stale data in Scattered across invocationsMatt Wala2015-06-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Scalarizer has two data structures that hold information about changes to the function, Gathered and Scattered. These are cleared in finish() at the end of runOnFunction() if finish() detects any changes to the function. However, finish() was checking for changes by only checking if Gathered was non-empty. The function visitStore() only modifies Scattered without touching Gathered. As a result, Scattered could have ended up having stale data if Scalarizer only scalarized store instructions. Since the data in Scattered is used during the execution of the pass, this introduced dangling pointer errors. The fix is to check whether both Scattered and Gathered are empty before deciding what to do in finish(). Reviewers: srhines Reviewed By: srhines Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10422 llvm-svn: 239644
* Fix a typo in a comment in MemCpyOpt (test commit)Matt Wala2015-06-121-1/+1
| | | | llvm-svn: 239628
* [GVN] Use a simpler form of IRBuilder constructor.Alexey Samsonov2015-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A side effect of this change is that it IRBuilder now automatically created debug info locations for new instructions, which is the same as debug location of insertion point. This is fine for the functions in questions (GetStoreValueForLoad and GetMemInstValueForLoad), as they are used in two situations: * GVN::processLoad, which tries to eliminate a load. In this case new instructions would have the same debug location as the load they eventually replace; * MaterializeAdjustedValue, which adds new instructions to the end of the basic blocks, which could later be used to replace the load definition. In this case we don't yet know the way the load would be eventually replaced (either by assembling the precomputed values via PHI, or by using them directly), so just using the basic block strategy seems to be reasonable. There is also a special case in the code that *would* adjust the location of the last instruction replacing the load definition to the location of the load. Test Plan: regression test suite Reviewers: echristo, dberlin, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10405 llvm-svn: 239585
* [GVN] Use IRBuilder more actively instead of creating instructions manually.Alexey Samsonov2015-06-121-20/+21
| | | | llvm-svn: 239584
* Update stale comment before analyzeLoopUnrollCost. NFC.Michael Zolotukhin2015-06-111-7/+9
| | | | llvm-svn: 239565
* SLSR: Pass address space to isLegalAddressingModeMatt Arsenault2015-06-111-1/+3
| | | | | | | | | This only updates one of the uses. The other is used in cases that may never touch memory, so I'm not sure why this is even calling it. Perhaps there should be a new, similar hook for such cases or pass -1 for unknown address space. llvm-svn: 239540
* [GVN] Set proper debug locations for some instructions created by GVN.Alexey Samsonov2015-06-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Determining proper debug locations for instructions created in PHITransAddr is tricky. We use a simple approach here and simply copy debug locations from instructions computing load address to "corresponding" instructions re-creating the address computation in predecessor basic blocks. This may not always be correct, given all the rearrangement and simplification going on, and debug locations may jump around a lot, as the basic blocks we copy locations between may be very far from each other. Still, this would work good in most simple cases (e.g. when chain of address computing instruction is short, or our mapping turns out to be 1-to-1), and we desire to have *some* reasonable debug locations associated with newly inserted instructions. See http://reviews.llvm.org/D10351 review thread for more details. Test Plan: regression test suite Reviewers: spatel, dblaikie Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10351 llvm-svn: 239479
* Remove DisableTailCalls from TargetOptions and the code in resetTargetOptionsAkira Hatanaka2015-06-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | that was resetting it. Remove the uses of DisableTailCalls in subclasses of TargetLowering and use the value of function attribute "disable-tail-calls" instead. Also, unconditionally add pass TailCallElim to the pipeline and check the function attribute at the start of runOnFunction to disable the pass on a per-function basis. This is part of the work to remove TargetMachine::resetTargetOptions, and since DisableTailCalls was the last non-fast-math option that was being reset in that function, we should be able to remove the function entirely after the work to propagate IR-level fast-math flags to DAG nodes is completed. Out-of-tree users should remove the uses of DisableTailCalls and make changes to attach attribute "disable-tail-calls"="true" or "false" to the functions in the IR. rdar://problem/13752163 Differential Revision: http://reviews.llvm.org/D10099 llvm-svn: 239427
* [ARM] Pass a callback to FunctionPass constructors to enable skipping executionAkira Hatanaka2015-06-081-3/+12
| | | | | | | | | | | | | | | | on a per-function basis. Previously some of the passes were conditionally added to ARM's pass pipeline based on the target machine's subtarget. This patch makes changes to add those passes unconditionally and execute them conditonally based on the predicate functor passed to the pass constructors. This enables running different sets of passes for different functions in the module. rdar://problem/20542263 Differential Revision: http://reviews.llvm.org/D8717 llvm-svn: 239325
* Remove SCEVCache and FindConstantPointers from complete loop unrolling ↵Michael Zolotukhin2015-06-081-212/+89
| | | | | | | | | | | | | | | | | | | | heuristic. Summary: Using some SCEV functionality helped to entirely remove SCEVCache class and FindConstantPointers SCEV visitor. Also, this makes the code more universal - I'll take advandate of it in next patches where I start handling additional types of instructions. Test Plan: Tests would be submitted in subsequent patches. Reviewers: atrick, chandlerc Reviewed By: atrick, chandlerc Subscribers: atrick, llvm-commits Differential Revision: http://reviews.llvm.org/D10205 llvm-svn: 239282
* SeparateConstOffsetFromGEP: Pass address space to isLegalAddressingModeMatt Arsenault2015-06-071-1/+3
| | | | llvm-svn: 239262
* Make NaryReassociate pass the address space to isLegalAddressingModeMatt Arsenault2015-06-071-1/+3
| | | | | | | No test since the kinds of transforms this prevents seem to not really be relevant for SI's different addressing modes. llvm-svn: 239261
* Remove global std::string. NFC.Benjamin Kramer2015-06-071-1/+1
| | | | llvm-svn: 239254
* [LoopUnroll] Fix truncation bug in canUnrollCompletely.Sanjoy Das2015-06-061-3/+3
| | | | | | | | | | | | | | | | | Summary: canUnrollCompletely takes `unsigned` values for `UnrolledCost` and `RolledDynamicCost` but is passed in `uint64_t`s that are silently truncated. Because of this, when `UnrolledSize` is a large integer that has a small remainder with UINT32_MAX, LLVM tries to completely unroll loops with high trip counts. Reviewers: mzolotukhin, chandlerc Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10293 llvm-svn: 239218
* [CVP] Don't assume Constants of type i1 can be known to be true or falseDavid Majnemer2015-06-061-3/+4
| | | | | | | | | | | | | CVP wants to analyze the condition operand of a select along an edge. It succeeds in getting back a Constant but not a ConstantInt. Instead, it gets a ConstantExpr. It then assumes that the Constant must be equal to false because it isn't equal to true. Instead, perform an additional comparison. This fixes PR23752. llvm-svn: 239217
* [Unroll] Rework the naming and structure of the new unroll heuristics.Chandler Carruth2015-06-051-95/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new naming is (to me) much easier to understand. Here is a summary of the new state of the world: - '*Threshold' is the threshold for full unrolling. It is measured against the estimated unrolled cost as computed by getUserCost in TTI (or CodeMetrics, etc). We will exceed this threshold when unrolling loops where unrolling exposes a significant degree of simplification of the logic within the loop. - '*PercentDynamicCostSavedThreshold' is the percentage of the loop's estimated dynamic execution cost which needs to be saved by unrolling to apply a discount to the estimated unrolled cost. - '*DynamicCostSavingsDiscount' is the discount applied to the estimated unrolling cost when the dynamic savings are expected to be high. When actually analyzing the loop, we now produce both an estimated unrolled cost, and an estimated rolled cost. The rolled cost is notably a dynamic estimate based on our analysis of the expected execution of each iteration. While we're still working to build up the infrastructure for making these estimates, to me it is much more clear *how* to make them better when they have reasonably descriptive names. For example, we may want to apply estimated (from heuristics or profiles) dynamic execution weights to the *dynamic* cost estimates. If we start doing that, we would also need to track the static unrolled cost and the dynamic unrolled cost, as only the latter could reasonably be weighted by profile information. This patch is sadly not without functionality change for the new unroll analysis logic. Buried in the heuristic management were several things that surprised me. For example, we never subtracted the optimized instruction count off when comparing against the unroll heursistics! I don't know if this just got lost somewhere along the way or what, but with the new accounting of things, this is much easier to keep track of and we use the post-simplification cost estimate to compare to the thresholds, and use the dynamic cost reduction ratio to select whether we can exceed the baseline threshold. The old values of these flags also don't necessarily make sense. My impression is that none of these thresholds or discounts have been tuned yet, and so they're just arbitrary placehold numbers. As such, I've not bothered to adjust for the fact that this is now a discount and not a tow-tier threshold model. We need to tune all these values once the logic is ready to be enabled. Differential Revision: http://reviews.llvm.org/D9966 llvm-svn: 239164
* [PM/AA] Start refactoring AliasAnalysis to remove the analysis group andChandler Carruth2015-06-044-24/+24
| | | | | | | | | | | | | | | | | | | | | port it to the new pass manager. All this does is extract the inner "location" class used by AA into its own full fledged type. This seems *much* cleaner as MemoryDependence and soon MemorySSA also use this heavily, and it doesn't make much sense being inside the AA infrastructure. This will also make it much easier to break apart the AA infrastructure into something that stands on its own rather than using the analysis group design. There are a few places where this makes APIs not make sense -- they were taking an AliasAnalysis pointer just to build locations. I'll try to clean those up in follow-up commits. Differential Revision: http://reviews.llvm.org/D10228 llvm-svn: 239003
* Remove stray semicolon. NFC.Vasileios Kalintiris2015-06-031-1/+1
| | | | llvm-svn: 238908
* [RewriteStatepointsForGC] Strip deref info after rewriting.Sanjoy Das2015-06-021-0/+102
| | | | | | | | | | | | | | | | | | | | | Summary: Once a gc.statepoint has been rewritten to relocate live references, the SSA values represent physical pointers instead of logical references. Logical dereferencability does not imply physical dereferencability and after RewriteStatepointsForGC has run any attributes that imply dereferencability of the logical references need to be stripped. This current approach is conservative, and can be made more precise later if needed. For starters, we need to strip dereferencable attributes only from pointers that live in the GC address space. Reviewers: reames, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10105 llvm-svn: 238883
* [NFCI] Change RewriteStatepointsForGC to a ModulePass.Sanjoy Das2015-06-021-13/+16
| | | | | | | | | | | | | | Summary: A later change that has RewriteStatepointsForGC change function attributes throughout the module depends on this. Reviewers: reames, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10104 llvm-svn: 238882
* Teach the IR Sink pass to (conservatively) respect convergent annotations.Owen Anderson2015-06-011-0/+6
| | | | llvm-svn: 238762
* Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial typesBenjamin Kramer2015-05-293-10/+10
| | | | | | | | | | | | | | | | | | | | If the type isn't trivially moveable emplace can skip a potentially expensive move. It also saves a couple of characters. Call sites were found with the ASTMatcher + some semi-automated cleanup. memberCallExpr( argumentCountIs(1), callee(methodDecl(hasName("push_back"))), on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))), hasArgument(0, bindTemporaryExpr( hasType(recordDecl(hasNonTrivialDestructor())), has(constructExpr()))), unless(isInTemplateInstantiation())) No functional change intended. llvm-svn: 238602
* Enable exitValue rewrite only when the cost of expansion is low.Wei Mi2015-05-281-15/+129
| | | | | | | | The patch evaluates the expansion cost of exitValue in indVarSimplify pass, and only does the rewriting when the expansion cost is low or loop can be deleted with the rewriting. It provides an option "-replexitval=" to control the default aggressiveness of the exitvalue rewriting. It also fixes some missing cases in SCEVExpander::isHighCostExpansionHelper to enhance the evaluation of SCEV expansion cost. Differential Revision: http://reviews.llvm.org/D9800 llvm-svn: 238507
* [Reassociate] Canonicalizing 'x [+-] (-Constant * y)' isn't always a winDavid Majnemer2015-05-281-35/+21
| | | | | | | | | | | | | Canonicalizing 'x [+-] (-Constant * y)' is not a win if we don't *know* we will open up CSE opportunities. If the multiply was 'nsw', then negating 'y' requires us to clear the 'nsw' flag. If this is actually worth pursuing, it is probably more appropriate to do so in GVN or EarlyCSE. This fixes PR23675. llvm-svn: 238397
* [NaryReassociate] Run EarlyCSE after NaryReassociateJingyue Wu2015-05-281-1/+23
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch made two improvements to NaryReassociate and the NVPTX pipeline 1. Run EarlyCSE/GVN after NaryReassociate to get rid of redundant common expressions. 2. When adding an instruction to SeenExprs, maps both the SCEV before and after reassociation to that instruction. Test Plan: updated @reassociate_gep_nsw in nary-gep.ll Reviewers: meheff, broune Reviewed By: broune Subscribers: dberlin, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D9947 llvm-svn: 238396
* [PlaceSafepoints] Entry safepoint location doesn't need to be a terminatorPhilip Reames2015-05-261-17/+1
| | | | | | | | | | Long ago, the poll insertion code assumed that the insertion site was a terminator. As a result, the entry selection code would split a basic block to ensure it could pass a terminator. The insertion code was updated quite a while ago - possibly before it ever landed upstream - but the now redundant work was never removed. While I'm at it, remove a comment which doesn't apply to the upstreamed code. NFC intended. llvm-svn: 238254
* [PlaceSafepoints] Cleanup InsertSafepointPoll functionPhilip Reames2015-05-261-20/+17
| | | | | | While working on another change, I noticed that the naming in this function was mildly deceptive. While fixing that, I took the oppurtunity to modernize some of the code. NFC intended. llvm-svn: 238252
* Use range-based for loops. NFC.Craig Topper2015-05-251-130/+84
| | | | llvm-svn: 238154
* Reformat.NAKAMURA Takumi2015-05-252-4/+3
| | | | llvm-svn: 238126
* Prune CRLFs.NAKAMURA Takumi2015-05-252-23/+23
| | | | llvm-svn: 238125
* [Unroll] Switch from an eagerly populated SCEV cache to one that isChandler Carruth2015-05-251-89/+116
| | | | | | | | | | lazily built. Also, make it a much more generic SCEV cache, which today exposes only a reduced GEP model description but could be extended in the future to do other profitable caching of SCEV information. llvm-svn: 238124
* Give more meaningful names than I and J to some for loop variables after ↵Craig Topper2015-05-231-10/+10
| | | | | | converting to range-based loops. llvm-svn: 238095
* Fix an unused variable warning in release builds.Craig Topper2015-05-231-0/+1
| | | | llvm-svn: 238094
* Use range-based for loops. NFC.Craig Topper2015-05-231-76/+36
| | | | llvm-svn: 238093
* Extend EarlyCSE to handle basic cases from JumpThreading and CVPPhilip Reames2015-05-222-21/+26
| | | | | | | | | | | | | | This patch extends EarlyCSE to take advantage of the information that a controlling branch gives us about the value of a Value within this and dominated basic blocks. If the current block has a single predecessor with a controlling branch, we can infer what the branch condition must have been to execute this block. The actual change to support this is downright simple because EarlyCSE's existing scoped hash table logic deals with most of the complexity around merging. The patch actually implements two optimizations. 1) The first is analogous to JumpThreading in that it enables EarlyCSE's CSE handling to fold branches which are exactly redundant due to a previous branch to branches on constants. (It doesn't actually replace the branch or change the CFG.) This is pretty clearly a win since it enables substantial CFG simplification before we start trying to inline. 2) The second is analogous to CVP in that it exploits the knowledge gained to replace dominated *uses* of the original value. EarlyCSE does not otherwise reason about specific uses, so this is the more arguable one. It does enable further simplication and constant folding within the rest of the visit by EarlyCSE. In both cases, the added code only handles the easy dominance based case of each optimization. The general case is deferred to the existing passes. Differential Revision: http://reviews.llvm.org/D9763 llvm-svn: 238071
* [Unroll] Separate the logic for testing each iteration of the loop,Chandler Carruth2015-05-221-106/+111
| | | | | | | | | | | | | | | | | | accumulating estimated cost, and other loop-centric logic from the logic used to analyze instructions in a particular iteration. This makes the visitor very narrow in scope -- all it does is visit instructions, update a map of simplified values, and return whether it is able to optimize away a particular instruction. The two cost metrics are now returned as an optional struct. When the optional is left unengaged, there is no information about the unrolled cost of the loop, when it is engaged the cost metrics are available to run against the thresholds. No functionality changed. llvm-svn: 238033
* [Unroll] Replace a hand-wavy FIXME with a FIXME that explains the actualChandler Carruth2015-05-221-1/+6
| | | | | | | problem instead of suggesting doing something that is trivial to do but incorrect given the current design of the libraries. llvm-svn: 237994
* [Unroll] Extract the logic for caching SCEV-modeled GEPs with theirChandler Carruth2015-05-221-67/+81
| | | | | | | | | | | | | | | | | | | simplified model for use simulating each iteration into a separate helper function that just returns the cache. Building this cache had nothing to do with the rest of the unroll analysis and so this removes an unnecessary coupling, etc. It should also make it easier to think about the concept of providing fast cached access to basic SCEV models as an orthogonal concept to the overall unroll simulation. I'd really like to see this kind of caching logic folded into SCEV itself, it seems weird for us to provide it at this layer rather than making repeated queries into SCEV fast all on their own. No functionality changed. llvm-svn: 237993
* [Unroll] Refactor the accumulation of optimized instruction costs intoChandler Carruth2015-05-221-9/+10
| | | | | | | | | | | | a single location. This reduces code duplication a bit and will also pave the way for a better separation between the visitation algorithm and the unroll analysis. No functionality changed. llvm-svn: 237990
* [LICM] Sinking doesn't involve the preheaderPhilip Reames2015-05-221-5/+11
| | | | | | PR23608 pointed out that using the preheader to gain a context instruction isn't always legal because a loop might not have a preheader. When looking into that, I realized that using the preheader to determine legality for sinking is questionable at best. Given no test covers that case and the original commit didn't seem to intend it, I restructured the code to only ask context sensative queries for hoising of loads and stores. This is effectively a partial revert of 237593. llvm-svn: 237985
* MergedLoadStoreMotion preserves MemoryDependenceAnalysis, it does not ↵Daniel Berlin2015-05-221-2/+2
| | | | | | | | require it. (It already was coded assuming it can sometimes be null, so no other changes are necessary) llvm-svn: 237978
* [NaryReassoc] reassociate GEP for CSEJingyue Wu2015-05-211-21/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: x = &a[i]; y = &a[i + j]; => y = x + j; along with some refactoring work such as extracting method findClosestMatchingDominator. Depends on D9786 which provides the ScalarEvolution::getGEPExpr interface. Test Plan: nary-gep.ll Reviewers: meheff, broune Reviewed By: broune Subscribers: jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D9802 llvm-svn: 237971
OpenPOWER on IntegriCloud