summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Scalar
Commit message (Collapse)AuthorAgeFilesLines
* [SROA] Cleanup - remove the use of std::mem_fun_ref nonsense and useChandler Carruth2014-12-181-1/+3
| | | | | | a lambda now that we have them. llvm-svn: 224500
* Sink store based on alias analysisElena Demikhovsky2014-12-151-40/+35
| | | | | | | | | | | | - by Ella Bolshinsky The alias analysis is used define whether the given instruction is a barrier for store sinking. For 2 identical stores, following instructions are checked in the both basic blocks, to determine whether they are sinking barriers. http://reviews.llvm.org/D6420 llvm-svn: 224247
* [Reassociate] Use dbgs() instead of errs().Chad Rosier2014-12-121-2/+2
| | | | llvm-svn: 224125
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-093-21/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split `Metadata` away from the `Value` class hierarchy, as part of PR21532. Assembly and bitcode changes are in the wings, but this is the bulk of the change for the IR C++ API. I have a follow-up patch prepared for `clang`. If this breaks other sub-projects, I apologize in advance :(. Help me compile it on Darwin I'll try to fix it. FWIW, the errors should be easy to fix, so it may be simpler to just fix it yourself. This breaks the build for all metadata-related code that's out-of-tree. Rest assured the transition is mechanical and the compiler should catch almost all of the problems. Here's a quick guide for updating your code: - `Metadata` is the root of a class hierarchy with three main classes: `MDNode`, `MDString`, and `ValueAsMetadata`. It is distinct from the `Value` class hierarchy. It is typeless -- i.e., instances do *not* have a `Type`. - `MDNode`'s operands are all `Metadata *` (instead of `Value *`). - `TrackingVH<MDNode>` and `WeakVH` referring to metadata can be replaced with `TrackingMDNodeRef` and `TrackingMDRef`, respectively. If you're referring solely to resolved `MDNode`s -- post graph construction -- just use `MDNode*`. - `MDNode` (and the rest of `Metadata`) have only limited support for `replaceAllUsesWith()`. As long as an `MDNode` is pointing at a forward declaration -- the result of `MDNode::getTemporary()` -- it maintains a side map of its uses and can RAUW itself. Once the forward declarations are fully resolved RAUW support is dropped on the ground. This means that uniquing collisions on changing operands cause nodes to become "distinct". (This already happened fairly commonly, whenever an operand went to null.) If you're constructing complex (non self-reference) `MDNode` cycles, you need to call `MDNode::resolveCycles()` on each node (or on a top-level node that somehow references all of the nodes). Also, don't do that. Metadata cycles (and the RAUW machinery needed to construct them) are expensive. - An `MDNode` can only refer to a `Constant` through a bridge called `ConstantAsMetadata` (one of the subclasses of `ValueAsMetadata`). As a side effect, accessing an operand of an `MDNode` that is known to be, e.g., `ConstantInt`, takes three steps: first, cast from `Metadata` to `ConstantAsMetadata`; second, extract the `Constant`; third, cast down to `ConstantInt`. The eventual goal is to introduce `MDInt`/`MDFloat`/etc. and have metadata schema owners transition away from using `Constant`s when the type isn't important (and they don't care about referring to `GlobalValue`s). In the meantime, I've added transitional API to the `mdconst` namespace that matches semantics with the old code, in order to avoid adding the error-prone three-step equivalent to every call site. If your old code was: MDNode *N = foo(); bar(isa <ConstantInt>(N->getOperand(0))); baz(cast <ConstantInt>(N->getOperand(1))); bak(cast_or_null <ConstantInt>(N->getOperand(2))); bat(dyn_cast <ConstantInt>(N->getOperand(3))); bay(dyn_cast_or_null<ConstantInt>(N->getOperand(4))); you can trivially match its semantics with: MDNode *N = foo(); bar(mdconst::hasa <ConstantInt>(N->getOperand(0))); baz(mdconst::extract <ConstantInt>(N->getOperand(1))); bak(mdconst::extract_or_null <ConstantInt>(N->getOperand(2))); bat(mdconst::dyn_extract <ConstantInt>(N->getOperand(3))); bay(mdconst::dyn_extract_or_null<ConstantInt>(N->getOperand(4))); and when you transition your metadata schema to `MDInt`: MDNode *N = foo(); bar(isa <MDInt>(N->getOperand(0))); baz(cast <MDInt>(N->getOperand(1))); bak(cast_or_null <MDInt>(N->getOperand(2))); bat(dyn_cast <MDInt>(N->getOperand(3))); bay(dyn_cast_or_null<MDInt>(N->getOperand(4))); - A `CallInst` -- specifically, intrinsic instructions -- can refer to metadata through a bridge called `MetadataAsValue`. This is a subclass of `Value` where `getType()->isMetadataTy()`. `MetadataAsValue` is the *only* class that can legally refer to a `LocalAsMetadata`, which is a bridged form of non-`Constant` values like `Argument` and `Instruction`. It can also refer to any other `Metadata` subclass. (I'll break all your testcases in a follow-up commit, when I propagate this change to assembly.) llvm-svn: 223802
* StructurizeCFG: Use LoopInfo analysis for better loop detectionTom Stellard2014-12-031-1/+6
| | | | | | | | We were assuming that each back-edge in a region represented a unique loop, which is not always the case. We need to use LoopInfo to correctly determine which back-edges are loops. llvm-svn: 223199
* [LICM] Avoind store sinking if no preheader is availableBruno Cardoso Lopes2014-12-021-2/+4
| | | | | | | | | Load instructions are inserted into loop preheaders when sinking stores and later removed if not used by the SSA updater. Avoid sinking if the loop has no preheader and avoid crashes. This fixes one more side effect of not handling indirectbr instructions properly on LoopSimplify. llvm-svn: 223119
* [LICM] Store sink and indirectbr instructionsBruno Cardoso Lopes2014-11-281-0/+6
| | | | | | | | | | | | | | Loop simplify skips exit-block insertion when exits contain indirectbr instructions. This leads to an assertion in LICM when trying to sink stores out of non-dedicated loop exits containing indirectbr instructions. This patch fix this issue by re-checking for dedicated exits in LICM prior to store sink attempts. Differential Revision: http://reviews.llvm.org/D6414 rdar://problem/18943047 llvm-svn: 222927
* Revert r220349 to re-instate r220277 with a fix for PR21330 -- quiteChandler Carruth2014-11-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | clearly only exactly equal width ptrtoint and inttoptr casts are no-op casts, it says so right there in the langref. Make the code agree. Original log from r220277: Teach the load analysis to allow finding available values which require inttoptr or ptrtoint cast provided there is datalayout available. Eventually, the datalayout can just be required but in practice it will always be there today. To go with the ability to expose available values requiring a ptrtoint or inttoptr cast, helpers are added to perform one of these three casts. These smarts are necessary to finish canonicalizing loads and stores to the operational type requirements without regressing fundamental combines. I've added some test cases. These should actually improve as the load combining and store combining improves, but they may fundamentally be highlighting some missing combines for select in addition to exercising the specific added logic to load analysis. llvm-svn: 222739
* This Reassociate change unintentionally slipped in r222499David Majnemer2014-11-211-7/+0
| | | | llvm-svn: 222500
* SROA: The alloca type isn't a candidate promotion type for vectorsDavid Majnemer2014-11-212-3/+9
| | | | | | | | | | | | The alloca's type is irrelevant, only those types which are used in a load or store of the exact size of the slice should be considered. This manifested as an assertion failure when we compared the various types: we had a size mismatch. This fixes PR21480. llvm-svn: 222499
* Revert "[Reassociate] As the expression tree is rewritten make sure the ↵Chad Rosier2014-11-191-8/+7
| | | | | | | | | | | | | operands are" This reverts commit r222142. This is causing/exposing an execution-time regression in spec2006/gcc and coremark on AArch64/A57/Ofast. Conflicts: test/Transforms/Reassociate/optional-flags.ll llvm-svn: 222398
* Fix tail recursion eliminationArnaud A. de Grandmaison2014-11-191-3/+25
| | | | | | | | | | | | | | | | | | | | | | When the BasicBlock containing the return instrution has a PHI with 2 incoming values, FoldReturnIntoUncondBranch will remove the no longer used incoming value and remove the no longer needed phi as well. This leaves us with a BB that no longer has a PHI, but the subsequent call to FoldReturnIntoUncondBranch from FoldReturnAndProcessPred will not remove the return instruction (which still uses the result of the call instruction). This prevents EliminateRecursiveTailCall to remove the value, as it is still being used in a basicblock which has no predecessors. The basicblock can not be erased on the spot, because its iterator is still being used in runTRE. This issue was exposed when removing the threshold on size for lifetime marker insertion for named temporaries in clang. The testcase is a much reduced version of peelOffOuterExpr(const Expr*, const ExplodedNode *) from clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp. llvm-svn: 222354
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-1911-31/+32
| | | | | | | | | | | | | pair<iterator, bool> This is to be consistent with StringSet and ultimately with the standard library's associative container insert function. This lead to updating SmallSet::insert to return pair<iterator, bool>, and then to update SmallPtrSet::insert to return pair<iterator, bool>, and then to update all the existing users of those functions... llvm-svn: 222334
* [SeparateConstOffsetFromGEP] Allow SeparateConstOffsetFromGEP pass to lower ↵Hao Liu2014-11-191-40/+272
| | | | | | | | | | | | GEPs. If LowerGEP is enabled, it can lower a GEP with multiple indices into GEPs with a single index or arithmetic operations. Lowering GEPs can always extract structure indices. Lowering GEPs can also give use more optimization opportunities. It can benefit passes like CSE, LICM and CGP. Reviewed in http://reviews.llvm.org/D5864 llvm-svn: 222328
* Revert r222039 because of bot failure.Manman Ren2014-11-191-175/+161
| | | | | | | http://lab.llvm.org:8080/green/job/clang-Rlto_master/298/ Hopefully, bot will be green. If not, we will re-submit the commit. llvm-svn: 222287
* [Reassociate] Rename local variable to not use same name as a memberChad Rosier2014-11-181-4/+4
| | | | | | variable. NFC. llvm-svn: 222248
* Tweak EarlyCSE to recognize series of dead storesPhilip Reames2014-11-181-1/+1
| | | | | | | | | EarlyCSE is giving up on the current instruction immediately when it recognizes that the current instruction makes a previous store trivially dead. There's no reason to do this. Once the previous store has been deleted, it's perfectly legal to remember the value of the current store (for value forwarding) and the fact the store occurred (it could be dead too!). Reviewed by: Hal Differential Revision: http://reviews.llvm.org/D6301 llvm-svn: 222241
* IndVarSimplify: Allow LFTR to fire more oftenDavid Majnemer2014-11-181-1/+22
| | | | | | | | | | | | | I added a pessimization in r217102 to prevent miscompiles when the incremented induction variable was used in a comparison; it would be poison. Try to use the incremented induction variable more often when we can be sure that the increment won't end in poison. Differential Revision: http://reviews.llvm.org/D6222 llvm-svn: 222213
* [Reassociate] As the expression tree is rewritten make sure the operands areChad Rosier2014-11-171-7/+8
| | | | | | emitted in canonical form. llvm-svn: 222142
* [Reassociate] Canonicalize constants to RHS operand.Chad Rosier2014-11-171-1/+4
| | | | | | Fix a thinko where the RHS was already a constant. llvm-svn: 222139
* Reapply r221924: "[GVN] Perform Scalar PRE on gep indices that feed loads beforeChad Rosier2014-11-141-161/+175
| | | | | | | | | | | | | | | | | doing Load PRE" This commit updates the failing test in Analysis/TypeBasedAliasAnalysis/gvn-nonlocal-type-mismatch.ll The failing test is sensitive to the order in which we process loads. This version turns on the RPO traversal instead of the while DT traversal in GVN. The new test code is functionally same just the order of loads that are eliminated is swapped. This new version also fixes an issue where GVN splits a critical edge and potentially invalidate the RPO/DT iterator. llvm-svn: 222039
* [Reassociate] Canonicalize the operands of all binary operators.Chad Rosier2014-11-141-12/+12
| | | | llvm-svn: 222008
* [Reassociate] Canonicalize operands of vector binary operators.Chad Rosier2014-11-141-6/+1
| | | | | | | | Prior to this commit fmul and fadd binary operators were being canonicalized for both scalar and vector versions. We now canonicalize add, mul, and, or, and xor vector instructions. llvm-svn: 222006
* [Reassociate] Canonicalize constants to RHS operand.Chad Rosier2014-11-141-12/+17
| | | | llvm-svn: 222005
* [Reassociate] Improve rank debug information. NFC.Chad Rosier2014-11-141-4/+5
| | | | llvm-svn: 221999
* Revert "[GVN] Perform Scalar PRE on gep indices that feed loads before doing ↵Chad Rosier2014-11-131-166/+166
| | | | | | | | | Load PRE." This reverts commit r221924. It appears the commit was a bit premature and is causing bot failures that need further investigation. llvm-svn: 221939
* [GVN] Perform Scalar PRE on gep indices that feed loads before doing Load PRE.Chad Rosier2014-11-131-166/+166
| | | | | | | Phabricator Revision: http://reviews.llvm.org/D6103 Patch by "Balaram Makam" <bmakam@codeaurora.org>! llvm-svn: 221924
* [Reassociate] Update comment. NFC.Chad Rosier2014-11-131-1/+1
| | | | llvm-svn: 221894
* Disable indvar widening if arithmetics on the wider type are more expensiveJingyue Wu2014-11-121-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reapply r221772. The old patch breaks the bot because the @indvar_32_bit test was run whether NVPTX was enabled or not. IndVarSimplify should not widen an indvar if arithmetics on the wider indvar are more expensive than those on the narrower indvar. For instance, although NVPTX64 treats i64 as a legal type, an ADD on i64 is twice as expensive as that on i32, because the hardware needs to simulate a 64-bit integer using two 32-bit integers. Split from D6188, and based on D6195 which adds NVPTXTargetTransformInfo. Fixes PR21148. Test Plan: Added @indvar_32_bit that verifies we do not widen an indvar if the arithmetics on the wider type are more expensive. This test is run only when NVPTX is enabled. Reviewers: jholewinski, eliben, meheff, atrick Reviewed By: atrick Subscribers: jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D6196 llvm-svn: 221799
* Reverts r221772 which fails testsJingyue Wu2014-11-121-30/+10
| | | | llvm-svn: 221773
* Disable indvar widening if arithmetics on the wider type are more expensiveJingyue Wu2014-11-121-10/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: IndVarSimplify should not widen an indvar if arithmetics on the wider indvar are more expensive than those on the narrower indvar. For instance, although NVPTX64 treats i64 as a legal type, an ADD on i64 is twice as expensive as that on i32, because the hardware needs to simulate a 64-bit integer using two 32-bit integers. Split from D6188, and based on D6195 which adds NVPTXTargetTransformInfo. Fixes PR21148. Test Plan: Added @indvar_32_bit that verifies we do not widen an indvar if the arithmetics on the wider type are more expensive. Reviewers: jholewinski, eliben, meheff, atrick Reviewed By: atrick Subscribers: jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D6196 llvm-svn: 221772
* [Reassociate] Canonicalize negative constants out of expressions.Chad Rosier2014-11-111-1/+2
| | | | | | Add support for FDiv, which was regressed by the previous commit. llvm-svn: 221738
* [Reassociate] Canonicalize negative constants out of expressions.Chad Rosier2014-11-111-42/+91
| | | | | | | | This is a reapplication of r221171, but we only perform the transformation on expressions which include a multiplication. We do not transform rem/div operations as this doesn't appear to be safe in all cases. llvm-svn: 221721
* Revert "IR: MDNode => Value"Duncan P. N. Exon Smith2014-11-111-2/+5
| | | | | | | | | | | | | | | | | Instead, we're going to separate metadata from the Value hierarchy. See PR21532. This reverts commit r221375. This reverts commit r221373. This reverts commit r221359. This reverts commit r221167. This reverts commit r221027. This reverts commit r221024. This reverts commit r221023. This reverts commit r220995. This reverts commit r220994. llvm-svn: 221711
* [Reassociate] Better preserve NSW/NUW flags.Chad Rosier2014-11-071-0/+11
| | | | | | | | Part of PR12985. Phabricator Revision: http://reviews.llvm.org/D6172 llvm-svn: 221555
* SCCP: overdefined calls cannot become constantDavid Majnemer2014-11-071-0/+3
| | | | | | | | | | We would attempt to fold away a call instruction which had been marked overdefined. However, it's not valid to transition to constant from overdefined. This fixes PR21512. llvm-svn: 221513
* [Reassociate] Don't reassociate when mixing regular and fast-math FPChad Rosier2014-11-061-3/+9
| | | | | | | | | instructions. Inlining might cause such cases and it's not valid to reassociate floating-point instructions without the unsafe algebra flag. Patch by Mehdi Amini <mehdi_amini@apple.com>! llvm-svn: 221462
* Revert "[Reassociate] Canonicalize negative constants out of expressions."Reid Kleckner2014-11-041-101/+42
| | | | | | | | | | | | This reverts commit r221171. It performs this invalid transformation: - %div.i = urem i64 -1, %add - %sub.i = sub i64 -2, %div.i + %div.i = urem i64 1, %add + %sub.i1 = add i64 %div.i, -2 llvm-svn: 221317
* Revert "Transforms: reapply SVN r219899"Reid Kleckner2014-11-041-2/+8
| | | | | | | This reverts commit r220811 and r220839. It made an incorrect change to musttail handling. llvm-svn: 221226
* Use AA in LoadCombineHal Finkel2014-11-031-4/+19
| | | | | | | | | | | | | | LoadCombine can be smarter about aborting when a writing instruction is encountered, instead of aborting upon encountering any writing instruction, use an AliasSetTracker, and only abort when encountering some write that might alias with the loads that could potentially be combined. This was originally motivated by comments made (and a test case provided) by David Majnemer in response to PR21448. It turned out that LoadCombine was not responsible for that PR, but LoadCombine should also be improved so that unrelated stores (and @llvm.assume) don't interrupt load combining. llvm-svn: 221203
* EarlyCSE should ignore calls to @llvm.assumeHal Finkel2014-11-031-0/+12
| | | | | | | | | | | | EarlyCSE uses a simple generation scheme for handling memory-based dependencies, and calls to @llvm.assume (which are marked as writing to memory to ensure the preservation of control dependencies) disturb that scheme unnecessarily. Skipping calls to @llvm.assume is legal, and the alternative (adding AA calls in EarlyCSE) is likely undesirable (we have GVN for that). Fixes PR21448. llvm-svn: 221175
* [Reassociate] Canonicalize negative constants out of expressions.Chad Rosier2014-11-031-42/+101
| | | | | | | | | This gives CSE/GVN more options to eliminate duplicate expressions. This is a follow up patch to http://reviews.llvm.org/D4904. http://reviews.llvm.org/D5363 llvm-svn: 221171
* IR: MDNode => Value: Instruction::getAllMetadataOtherThanDebugLoc()Duncan P. N. Exon Smith2014-11-031-3/+2
| | | | | | | Change `Instruction::getAllMetadataOtherThanDebugLoc()` from a vector of `MDNode` to one of `Value`. Part of PR21433. llvm-svn: 221167
* Use ErrorOr for the ::create factory on instrumented and sample profilers.Diego Novillo2014-11-031-2/+3
| | | | | | | | | | | | | | | | | Summary: As discussed in http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141027/242445.html, the creation of reader and writer instances is better done using ErrorOr. There are no functional changes, but several callers needed to be adjusted. Reviewers: bogner Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6076 llvm-svn: 221120
* Use Alias Analysis to hoist 2 loads from diamond to the common predecessor ↵Elena Demikhovsky2014-11-021-47/+25
| | | | | | | | | | basic block. Alias Analysis allows to detect real barriers for load hoisting. Review in http://reviews.llvm.org/D5991 llvm-svn: 221091
* Fix Twine corruption problem with diagnostics.Diego Novillo2014-10-301-2/+1
| | | | | | | This fixes the autobuilders I broke with a recent patch. Thanks echristo and dblaikie for beating me with a clue stick. llvm-svn: 220918
* Add profile writing capabilities for sampling profiles.Diego Novillo2014-10-301-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch finishes up support for handling sampling profiles in both text and binary formats. The new binary format uses uleb128 encoding to represent numeric values. This makes profiles files about 25% smaller. The profile writer class can write profiles in the existing text and the new binary format. In subsequent patches, I will add the capability to read (and perhaps write) profiles in the gcov format used by GCC. Additionally, I will be adding support in llvm-profdata to manipulate sampling profiles. There was a bit of refactoring needed to separate some code that was in the reader files, but is actually common to both the reader and writer. The new test checks that reading the same profile encoded as text or raw, produces the same results. Reviewers: bogner, dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6000 llvm-svn: 220915
* Do not simplifyLatch for loops where hoisting increments couldresult in ↵Yi Jiang2014-10-291-3/+30
| | | | | | extra live range interferance llvm-svn: 220872
* Transforms: reapply SVN r219899Saleem Abdulrasool2014-10-281-8/+2
| | | | | | | | | | | | | | | | This restores the commit from SVN r219899 with an additional change to ensure that the CodeGen is correct for the case that was identified as being incorrect (originally PR7272). In the case that during inlining we need to synthesize a value on the stack (i.e. for passing a value byval), then any function involving that alloca must be stripped of its tailness as the restriction that it does not access the parent's stack no longer holds. Unfortunately, a single alloca can cause a rippling effect through out the inlining as the value may be aliased or may be mutated through an escaped external call. As such, we simply track if an alloca has been introduced in the frame during inlining, and strip any tail calls. llvm-svn: 220811
* Reformat partially, where I touched for whitespace changes.NAKAMURA Takumi2014-10-281-6/+5
| | | | llvm-svn: 220773
OpenPOWER on IntegriCloud