summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* [BasicAA] Extract WriteOnly predicate on parameters [NFC]Philip Reames2016-01-061-5/+25
| | | | | | Since writeonly is the only missing attribute and special case left for the memset/memcpy family of intrinsics, rearrange the code to make that much more clear. llvm-svn: 256949
* Revert "GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and ↵Amaury Sechet2016-01-061-16/+1
| | | | | | | | | | | | | | | | | | | InaccessibleMemOrArgMemOnly attributes" Summary: This reverts commit 5a9e526f29cf8510ab5c3d566fbdcf47ac24e1e9. As per discussion in D15665 This also add a test case so that regression introduced by that diff are not reintroduced. Reviewers: vaivaswatha, jmolloy, hfinkel, reames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15919 llvm-svn: 256932
* [BasicAA] Remove special casing of memset_pattern16 in favor of generic ↵Philip Reames2016-01-061-12/+5
| | | | | | | | | | | | attribute inference Most of the properties of memset_pattern16 can be now covered by the generic attributes and inferred by InferFunctionAttrs. The only exceptions are: - We don't yet have a writeonly attribute for the first argument. - We don't have an attribute for modeling the access size facts encoded in MemoryLocation.cpp. Differential Revision: http://reviews.llvm.org/D15879 llvm-svn: 256911
* [BasicAA] Delete dead code related to memset/memcpy/memmove intrinsics [NFCI]Philip Reames2016-01-061-3/+5
| | | | | | | | We only need to describe the writeonly property of one of the arguments. All of the rest of the semantics are nicely described by existing attributes in Intrinsics.td. Differential Revision: http://reviews.llvm.org/D15880 llvm-svn: 256910
* [Statepoints] Refactor GCRelocateOperands into an intrinsic wrapper. NFC.Manuel Jacob2016-01-051-6/+3
| | | | | | | | | | | | | | | Summary: This commit renames GCRelocateOperands to GCRelocateInst and makes it an intrinsic wrapper, similar to e.g. MemCpyInst. Also, all users of GCRelocateOperands were changed to use the new intrinsic wrapper instead. Reviewers: sanjoy, reames Subscribers: reames, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15762 llvm-svn: 256811
* [MDA] Don't be quite as conservative for noalias functionsPhilip Reames2016-01-051-7/+7
| | | | | | | | | | If we encounter a noalias call that alias analysis can't analyse, we can fall down into the generic call handling rather than giving up entirely. I noticed this while reading through the code for another purpose. I can't seem to write a test case which changes; that sorta makes sense given any test case would have to be an inconsistency in AA. Suggestions welcome. Differential Revision: http://reviews.llvm.org/D15825 llvm-svn: 256802
* [MemoryBuiltins] Remove isOperatorNewLike by consolidating non-null ↵Philip Reames2016-01-042-11/+0
| | | | | | | | | | | | inference handling This patch removes the isOperatorNewLike predicate since it was only being used to establish a non-null return value and we have attributes specifically for that purpose with generic handling. To keep approximate the same behaviour for existing frontends, I added the various operator new like (i.e. instances of operator new) to InferFunctionAttrs. It's not really clear to me why this isn't handled in Clang, but I didn't want to break existing code and any subtle assumptions it might have. Once this patch is in, I'm going to start separating the isAllocLike family of predicates. These appear to be being used for a mixture of things which should be more clearly separated and documented. Today, they're being used to indicate (at least) aliasing facts, CSE-ability, and default values from an allocation site. Differential Revision: http://reviews.llvm.org/D15820 llvm-svn: 256787
* Fix comment in typo. NFCNick Lewycky2016-01-041-1/+1
| | | | llvm-svn: 256761
* Fix a horrible infloop in value tracking in the face of dead code.Chandler Carruth2016-01-041-1/+6
| | | | | | | | | | | | | | | Amazingly, we just never triggered this without: 1) Moving code around for MetadataTracking so that a certain *different* amount of inlining occurs in the per-TU compile step. 2) Then you LTO opt or clang with a bootstrap, and get inlining, loop opts, and GVN line up everything *just* right. I don't really know how we didn't hit this before. We really need to be fuzz testing stuff, it shouldn't be hard to trigger. I'm working on crafting a reduced nice test case, and will submit that when I have it, but I want to get LTO build bots going again. llvm-svn: 256735
* Use std::is_sorted and std::none_of instead of manual loops. NFCCraig Topper2016-01-032-11/+8
| | | | llvm-svn: 256719
* [ValueTracking] fix bug computing isKnownToBeAPowerOfTwo() with arithmetic ↵Sanjay Patel2015-12-301-2/+3
| | | | | | | | | | | | | | shift right (PR25900) This is a fix for: https://llvm.org/bugs/show_bug.cgi?id=25900 If we think that an arithmetic right shift of a power of two is always a power of two, an sdiv gets wrongly converted to udiv. Differential Revision: http://reviews.llvm.org/D15827 llvm-svn: 256655
* [MemoryBuiltins] Delete dead code [NFC]Philip Reames2015-12-291-7/+0
| | | | llvm-svn: 256565
* Refactor inline costs analysis by removing the InlineCostAnalysis classEaswaran Raman2015-12-281-36/+12
| | | | | | | | | | InlineCostAnalysis is an analysis pass without any need for it to be one. Once it stops being an analysis pass, it doesn't maintain any useful state and the member functions inside can be made free functions. NFC. Differential Revision: http://reviews.llvm.org/D15701 llvm-svn: 256521
* Implemented cost model for masked gather and scatter operationsElena Demikhovsky2015-12-282-3/+19
| | | | | | | | | The cost is calculated for all X86 targets. When gather/scatter instruction is not supported we calculate the cost of scalar sequence. Differential revision: http://reviews.llvm.org/D15677 llvm-svn: 256519
* [lcg] Fix a few more formatting goofs found by clang-format. NFC.Chandler Carruth2015-12-281-4/+4
| | | | llvm-svn: 256480
* Add a missing const qualifier on the context instruction. This somehowChandler Carruth2015-12-241-1/+1
| | | | | | has always been missing. =/ llvm-svn: 256371
* Fix SCEV r256338.JF Bastien2015-12-231-2/+2
| | | | llvm-svn: 256344
* [SCEV] Fix getLoopBackedgeTakenCountsSanjoy Das2015-12-231-17/+16
| | | | | | | | The way `getLoopBackedgeTakenCounts` is written right now isn't correct. It will try to compute and store the BE counts of a Loop #{child loop} number of times (which may be zero). llvm-svn: 256338
* [OperandBundles] Have GlobalsModRef play nice with operand bundlesDavid Majnemer2015-12-232-7/+6
| | | | | | | A call site's use of a Value might not correspond to an argument operand but to a bundle operand. llvm-svn: 256329
* Provide a way to specify inliner's attribute compatibility and merging.Akira Hatanaka2015-12-221-3/+1
| | | | | | | | | | | | | | | | | | | | | This reapplies r256277 with two changes: - In emitFnAttrCompatCheck, change FuncName's type to std::string to fix a use-after-free bug. - Remove an unnecessary install-local target in lib/IR/Makefile. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256304
* [BPI] Fix two potential divide-by-zero operations that are introduced in ↵Cong Hou2015-12-221-2/+8
| | | | | | r256263. llvm-svn: 256303
* Revert r256277 and r256279.Akira Hatanaka2015-12-221-1/+3
| | | | | | Some of the bots failed again. llvm-svn: 256280
* Provide a way to specify inliner's attribute compatibility and merging.Akira Hatanaka2015-12-221-3/+1
| | | | | | | | | | | | | | | | | | This reapplies r252990 and r252949. I've added member function getKind to the Attr classes which returns the enum or string of the attribute. Original commit message for r252949: Provide a way to specify inliner's attribute compatibility and merging rules using table-gen. NFC. This commit adds new classes CompatRule and MergeRule to Attributes.td, which are used to generate code to check attribute compatibility and merge attributes of the caller and callee. rdar://problem/19836465 llvm-svn: 256277
* [BPI] Replace weights by probabilities in BPI.Cong Hou2015-12-221-168/+119
| | | | | | | | | | | | This patch removes all weight-related interfaces from BPI and replace them by probability versions. With this patch, we won't use edge weight anymore in either IR or MC passes. Edge probabilitiy is a better representation in terms of CFG update and validation. Differential revision: http://reviews.llvm.org/D15519 llvm-svn: 256263
* Enhance BranchProbabilityInfo::calcUnreachableHeuristics for InvokeInstJun Bum Lim2015-12-211-0/+10
| | | | | | | | | | | | | | | This is recommit of r256028 with minor fixes in unittests: CodeGen/Mips/eh.ll CodeGen/Mips/insn-zero-size-bb.ll Original commit message: When identifying blocks post-dominated by an unreachable-terminated block in BranchProbabilityInfo, consider only the edge to the normal destination block if the terminator is InvokeInst and let calcInvokeHeuristics() decide edge weights for the InvokeInst. llvm-svn: 256202
* [ValueTracking] Properly handle non-sized types in isAligned function.Michael Zolotukhin2015-12-211-1/+5
| | | | | | | | | | Reviewers: apilipenko, reames, sanjoy, hfinkel Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15597 llvm-svn: 256192
* [DivergenceAnalysis] fix a bug in computing influence regionsJingyue Wu2015-12-181-7/+19
| | | | | | Fixes PR25864 llvm-svn: 256036
* Revert "Enhance BranchProbabilityInfo::calcUnreachableHeuristics for InvokeInst"Rafael Espindola2015-12-181-10/+0
| | | | | | | | | | | This reverts commit r256028. It broke: LLVM :: CodeGen/Mips/eh.ll LLVM :: CodeGen/Mips/insn-zero-size-bb.ll llvm-svn: 256032
* Enhance BranchProbabilityInfo::calcUnreachableHeuristics for InvokeInstJun Bum Lim2015-12-181-0/+10
| | | | | | | | | When identifying blocks post-dominated by an unreachable-terminated block in BranchProbabilityInfo, consider only the edge to the normal destination block if the terminator is InvokeInst and let calcInvokeHeuristics() decide edge weights for the InvokeInst. llvm-svn: 256028
* [WinEH] Update LCSSA to handle catchswitch with handlers inside and outside ↵Andrew Kaylor2015-12-181-1/+8
| | | | | | | | a loop Differential Revision: http://reviews.llvm.org/D15630 llvm-svn: 256005
* GlobalsAA: Take advantage of ArgMemOnly, InaccessibleMemOnly and ↵Vaivaswatha Nagaraj2015-12-181-1/+16
| | | | | | | | | | | | | | | | | | | | | InaccessibleMemOrArgMemOnly attributes Summary: 1. Modify AnalyzeCallGraph() to retain function info for external functions if the function has [InaccessibleMemOr]ArgMemOnly flags. 2. When analyzing the use of a global is function parameter at a call site, mark the callee also as modifying the global appropriately. 3. Add additional test cases. Depends on D15499 Reviewers: hfinkel, jmolloy Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15605 llvm-svn: 255994
* [SCEV] Add and use SCEVConstant::getAPInt; NFCISanjoy Das2015-12-175-119/+105
| | | | llvm-svn: 255921
* Revert r254592 (virtual dtor in SCEVPredicate).Andy Gibbs2015-12-171-2/+0
| | | | | | | | Clang has better diagnostics in this case. It is not necessary therefore to change the destructor to avoid what is effectively an invalid warning in gcc. Instead, better handle the warning flags given to the compiler. llvm-svn: 255905
* LPM: Make callers of LPM.deleteLoopFromQueue update LoopInfo directly. NFCJustin Bogner2015-12-161-6/+0
| | | | | | | | | | | As of r255720, the loop pass manager will DTRT when passes update the loop info for removed loops, so they no longer need to reach into LPPassManager APIs to do this kind of transformation. This change very nearly removes the need for the LPPassManager to even be passed into loop passes - the only remaining pass that uses the LPM argument is LoopUnswitch. llvm-svn: 255797
* Fix typo in r255720Justin Bogner2015-12-161-1/+1
| | | | llvm-svn: 255724
* LPM: Simplify how passes mark loops for deletion. NFCJustin Bogner2015-12-162-42/+17
| | | | | | | | | | | | | | | | | | | | When a pass removes a loop it currently has to reach up into the LPPassManager's internals to update the state of the iteration over loops. This reverse dependency results in a pretty awkward interplay of the LPPassManager and its Passes. Here, we change this to instead keep track of when a loop has become "unlooped" in the Loop objects themselves, then the LPPassManager can check this and manipulate its own state directly. This opens the door to allow most of the loop passes to work without a backreference to the LPPassManager. I've kept passes calling the LPPassManager::deleteLoopFromQueue API now so I could put an assert in to prove that this is NFC, but a later pass will update passes just to preserve the LoopInfo directly and stop referencing the LPPassManager completely. llvm-svn: 255720
* AMDGPU: mark ldexp LibCalls as unavailableNicolai Hahnle2015-12-151-0/+7
| | | | | | | | | | | | | | | | | | Summary: The LibCallSimplifier will turn llvm.exp2.* intrinsics into ldexp* libcalls which do not make sense with the AMDGPU backend. In the long run, we'll want an llvm.ldexp.* intrinsic to properly make use of this optimization, but this works around the problem for now. See also: http://reviews.llvm.org/D14327 (suggested llvm.ldexp.* implementation) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92709 Reviewers: arsenm, tstellarAMD Differential Revision: http://reviews.llvm.org/D14990 llvm-svn: 255658
* [IR] Remove terminatepadDavid Majnemer2015-12-143-6/+2
| | | | | | | | | | | | | It turns out that terminatepad gives little benefit over a cleanuppad which calls the termination function. This is not sufficient to implement fully generic filters but MSVC doesn't support them which makes terminatepad a little over-designed. Depends on D15478. Differential Revision: http://reviews.llvm.org/D15479 llvm-svn: 255522
* Try to appease a buildbotDavid Majnemer2015-12-121-0/+1
| | | | | | | | | The builder complains thusly: error C2027: use of undefined type 'llvm::raw_ostream' Try to make it happy by including raw_ostream.h llvm-svn: 255425
* [IR] Reformulate LLVM's EH funclet IRDavid Majnemer2015-12-126-17/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we have successfully implemented a funclet-oriented EH scheme on top of LLVM IR, our scheme has some notable deficiencies: - catchendpad and cleanupendpad are necessary in the current design but they are difficult to explain to others, even to seasoned LLVM experts. - catchendpad and cleanupendpad are optimization barriers. They cannot be split and force all potentially throwing call-sites to be invokes. This has a noticable effect on the quality of our code generation. - catchpad, while similar in some aspects to invoke, is fairly awkward. It is unsplittable, starts a funclet, and has control flow to other funclets. - The nesting relationship between funclets is currently a property of control flow edges. Because of this, we are forced to carefully analyze the flow graph to see if there might potentially exist illegal nesting among funclets. While we have logic to clone funclets when they are illegally nested, it would be nicer if we had a representation which forbade them upfront. Let's clean this up a bit by doing the following: - Instead, make catchpad more like cleanuppad and landingpad: no control flow, just a bunch of simple operands; catchpad would be splittable. - Introduce catchswitch, a control flow instruction designed to model the constraints of funclet oriented EH. - Make funclet scoping explicit by having funclet instructions consume the token produced by the funclet which contains them. - Remove catchendpad and cleanupendpad. Their presence can be inferred implicitly using coloring information. N.B. The state numbering code for the CLR has been updated but the veracity of it's output cannot be spoken for. An expert should take a look to make sure the results are reasonable. Reviewers: rnk, JosephTremoulet, andrew.w.kaylor Differential Revision: http://reviews.llvm.org/D15139 llvm-svn: 255422
* [LazyValueInfo] Stop inserting overdefined values into ValueCache toAkira Hatanaka2015-12-111-18/+48
| | | | | | | | | | | | | | | | | | reduce memory usage. Previously, LazyValueInfoCache inserted overdefined lattice values into both ValueCache and OverDefinedCache. This wasn't necessary and was causing LazyValueInfo to use an excessive amount of memory in some cases. This patch changes LazyValueInfoCache to insert overdefined values only into OverDefinedCache. The memory usage decreases by 70 to 75% when one of the files in llvm is compiled. rdar://problem/11388615 Differential revision: http://reviews.llvm.org/D15391 llvm-svn: 255320
* Re-commit r255115, with the PredicatedScalarEvolution class moved toSilviu Baranga2015-12-092-44/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ScalarEvolution.h, in order to avoid cyclic dependencies between the Transform and Analysis modules: [LV][LAA] Add a layer over SCEV to apply run-time checked knowledge on SCEV expressions Summary: This change creates a layer over ScalarEvolution for LAA and LV, and centralizes the usage of SCEV predicates. The SCEVPredicatedLayer takes the statically deduced knowledge by ScalarEvolution and applies the knowledge from the SCEV predicates. The end goal is that both LAA and LV should use this interface everywhere. This also solves a problem involving the result of SCEV expression rewritting when the predicate changes. Suppose we have the expression (sext {a,+,b}) and two predicates P1: {a,+,b} has nsw P2: b = 1. Applying P1 and then P2 gives us {a,+,1}, while applying P2 and the P1 gives us sext({a,+,1}) (the AddRec expression was changed by P2 so P1 no longer applies). The SCEVPredicatedLayer maintains the order of transformations by feeding back the results of previous transformations into new transformations, and therefore avoiding this issue. The SCEVPredicatedLayer maintains a cache to remember the results of previous SCEV rewritting results. This also has the benefit of reducing the overall number of expression rewrites. Reviewers: mzolotukhin, anemet Subscribers: jmolloy, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D14296 llvm-svn: 255122
* Revert r255115 until we figure out how to fix the bot failures.Silviu Baranga2015-12-091-44/+43
| | | | llvm-svn: 255117
* [LV][LAA] Add a layer over SCEV to apply run-time checked knowledge on SCEV ↵Silviu Baranga2015-12-091-43/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | expressions Summary: This change creates a layer over ScalarEvolution for LAA and LV, and centralizes the usage of SCEV predicates. The SCEVPredicatedLayer takes the statically deduced knowledge by ScalarEvolution and applies the knowledge from the SCEV predicates. The end goal is that both LAA and LV should use this interface everywhere. This also solves a problem involving the result of SCEV expression rewritting when the predicate changes. Suppose we have the expression (sext {a,+,b}) and two predicates P1: {a,+,b} has nsw P2: b = 1. Applying P1 and then P2 gives us {a,+,1}, while applying P2 and the P1 gives us sext({a,+,1}) (the AddRec expression was changed by P2 so P1 no longer applies). The SCEVPredicatedLayer maintains the order of transformations by feeding back the results of previous transformations into new transformations, and therefore avoiding this issue. The SCEVPredicatedLayer maintains a cache to remember the results of previous SCEV rewritting results. This also has the benefit of reducing the overall number of expression rewrites. Reviewers: mzolotukhin, anemet Subscribers: jmolloy, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D14296 llvm-svn: 255115
* [SCEV] Use for-each; NFCSanjoy Das2015-12-081-19/+13
| | | | llvm-svn: 255069
* [SCEV] Move some struct declarations inside functions; NFCSanjoy Das2015-12-081-63/+54
| | | | | | | | | Reduces the scope over which the struct is visible, making its usages obvious. I did not move structs in cases where this wasn't a clear win (the struct is too large, or is grouped in some other interesting way). llvm-svn: 255003
* [SCEV] Fix indentation; NFCSanjoy Das2015-12-081-150/+150
| | | | llvm-svn: 255002
* [IndVars] Have getInsertPointForUses preserve LCSSASanjoy Das2015-12-081-0/+9
| | | | | | | | | | | | | | | Summary: Also add a stricter post-condition for IndVarSimplify. Fixes PR25578. Test case by Michael Zolotukhin. Reviewers: hfinkel, atrick, mzolotukhin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15059 llvm-svn: 254977
* [SCEVExpander] Have hoistIVInc preserve LCSSASanjoy Das2015-12-081-0/+3
| | | | | | | | | | | | | | | | Summary: (Note: the problematic invocation of hoistIVInc that caused PR24804 came from IndVarSimplify, not from SCEVExpander itself) Fixes PR24804. Test case by David Majnemer. Reviewers: hfinkel, majnemer, atrick, mzolotukhin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D15058 llvm-svn: 254976
* Use updated threshold for indirect call bonusEaswaran Raman2015-12-071-2/+2
| | | | | | | | When considering foo->bar inlining, if there is an indirect call in foo which gets resolved to a direct call (say baz), then we try to inline baz into bar with a threshold T and subtract max(T - Cost(bar->baz), 0) from Cost(foo->bar). This patch uses max(Threshold(bar->baz) - Cost(bar->baz)) instead, where Thresheld(bar->baz) could be different from T due to bonuses or subtractions. Threshold(bar->baz) - Cost(bar->baz) better represents the desirability of inlining baz into bar. Differential Revision: http://reviews.llvm.org/D14309 llvm-svn: 254945
OpenPOWER on IntegriCloud