summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis
Commit message (Collapse)AuthorAgeFilesLines
...
* Recognize n/1 in the SCEV divide functionBrendon Cahoon2015-04-201-0/+7
| | | | | | | | | | | | n/1 generates a quotient equal to n and a remainder of 0. If this case is not recognized, then the SCEV divide() function can return a remainder that is greater than or equal to the denominator, which means the delinearized subscripts for the test case will be incorrect. Differential Revision: http://reviews.llvm.org/D9003 llvm-svn: 235311
* [LoopAccesses] Improve debug outputAdam Nemet2015-04-171-4/+8
| | | | llvm-svn: 235238
* DebugInfo: Gut DIType and subclassesDuncan P. N. Exon Smith2015-04-161-11/+11
| | | | | | | | Continuing PR23080, gut `DIType` and its various subclasses, leaving behind thin wrappers around the pointer types in the new debug info hierarchy. llvm-svn: 235064
* DebugInfo: Gut DICompileUnit and DIFileDuncan P. N. Exon Smith2015-04-151-4/+4
| | | | | | | Continuing gutting `DIDescriptor` subclasses; this edition, `DICompileUnit` and `DIFile`. In the name of PR23080. llvm-svn: 235055
* One more -Wrange-loop-analysis cleanup.Richard Trieu2015-04-151-1/+1
| | | | llvm-svn: 235044
* Add range iterators for post order and inverse post order. Use themDaniel Berlin2015-04-151-12/+10
| | | | llvm-svn: 235026
* Re-apply r234898 and fix tests.Daniel Jasper2015-04-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit makes LLVM not estimate branch probabilities when doing a single bit bitmask tests. The code that originally made me discover this is: if ((a & 0x1) == 0x1) { .. } In this case we don't actually have any branch probability information and should not assume to have any. LLVM transforms this into: %and = and i32 %a, 1 %tobool = icmp eq i32 %and, 0 So, in this case, the result of a bitwise and is compared against 0, but nevertheless, we should not assume to have probability information. CodeGen/ARM/2013-10-11-select-stalls.ll started failing because the changed probabilities changed the results of ARMBaseInstrInfo::isProfitableToIfCvt() and led to an Ifcvt of the diamond in the test. AFAICT, the test was never meant to test this and thus changing the test input slightly to not change the probabilities seems like the best way to preserve the meaning of the test. llvm-svn: 234979
* Change range-based for-loops to be -Wrange-loop-analysis clean.Richard Trieu2015-04-151-1/+1
| | | | | | No functionality change. llvm-svn: 234963
* [Inliner] Don't inline functions with frameescape callsReid Kleckner2015-04-141-8/+19
| | | | | | | | | | | Inlining such intrinsics is very difficult, since you need to simultaneously transform many calls to llvm.framerecover and potentially duplicate the functions containing them. Normally this intrinsic isn't added until EH preparation, which is part of the backend pass pipeline after inlining. However, if it were to get fed through the inliner, this change will ensure that it doesn't break the code. llvm-svn: 234937
* Revert "The code that originally made me discover this is:"Rafael Espindola2015-04-141-8/+0
| | | | | | | This reverts commit r234898. CodeGen/ARM/2013-10-11-select-stalls.ll was faling. llvm-svn: 234903
* Improve RefreshCallGraph to remove invalid call graph edge.Chad Rosier2015-04-141-4/+7
| | | | | | | | | | | | | With commit r219944, InstCombine can now turn a sqrtl into a llvm.fabs.f64. The call graph edge originally representing the call to sqrtl becomes invalid. This patch modifies CGPassManager::RefreshCallGraph() to remove the invalid call graph edge, which can triggers an assert in CallGraphNode::addCalledFunction(). Phabricator Review: http://reviews.llvm.org/D7705 Patch by Lawrence Hu <lawrence@codeaurora.org>. llvm-svn: 234902
* The code that originally made me discover this is:Daniel Jasper2015-04-141-0/+8
| | | | | | | | | | | | | | | | | | if ((a & 0x1) == 0x1) { .. } In this case we don't actually have any branch probability information and should not assume to have any. LLVM transforms this into: %and = and i32 %a, 1 %tobool = icmp eq i32 %and, 0 So, in this case, the result of a bitwise and is compared against 0, but nevertheless, we should not assume to have probability information. llvm-svn: 234898
* DebugInfo: Gut DISubprogram and DILexicalBlock*Duncan P. N. Exon Smith2015-04-141-5/+5
| | | | | | | Gut the `DIDescriptor` wrappers around `MDLocalScope` subclasses. Note that `DILexicalBlock` wraps `MDLexicalBlockBase`, not `MDLexicalBlock`. llvm-svn: 234850
* [SCEV] Strengthen SCEVExpander::isHighCostExpansion.Sanjoy Das2015-04-141-6/+17
| | | | | | | | | | | | | | | | | | Summary: Teach `isHighCostExpansion` to consider divisions by power-of-two constants as cheap and add a test case. This change is needed for a new user of `isHighCostExpansion` that will be added in a subsequent change. Depends on D8995. Reviewers: atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8993 llvm-svn: 234845
* [SCEV] Refactor out isHighCostExpansion. NFCI.Sanjoy Das2015-04-141-0/+56
| | | | | | | | | | | | | | Summary: Move isHighCostExpansion from IndVarSimplify to SCEVExpander. This exposed function will be used in a subsequent change. Reviewers: bogner, atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8995 llvm-svn: 234844
* DebugInfo: Gut DIVariable and DIGlobalVariableDuncan P. N. Exon Smith2015-04-141-4/+4
| | | | | | | | | | Gut all the non-pointer API from the variable wrappers, except an implicit conversion from `DIGlobalVariable` to `DIDescriptor`. Note that if you're updating out-of-tree code, `DIVariable` wraps `MDLocalVariable` (`MDVariable` is a common base class shared with `MDGlobalVariable`). llvm-svn: 234840
* [LoopAccesses] Properly print whether memchecks are neededAdam Nemet2015-04-141-3/+3
| | | | | | | | | | | Fix oversight in -analyze output. PtrRtCheck contains the pointers that need to be checked against each other and not whether memchecks are necessary. For instance in the testcase PtrRtCheck has four elements but all no-alias so no checking is necessary. llvm-svn: 234833
* Add new getModRefInfo API to determine whether an Instruction and a call ↵Daniel Berlin2015-04-131-0/+17
| | | | | | modify the same memory llvm-svn: 234814
* Common some code from MemoryDependenceAnalysis that will be used in MemorySSADaniel Berlin2015-04-131-17/+1
| | | | llvm-svn: 234813
* Make getModRefInfo with a default location not crash.Daniel Berlin2015-04-131-9/+12
| | | | | | | Add getModRefInfo that works without location. Add unit tests. llvm-svn: 234811
* [inliner] Don't inline a function if it doesn't have exactly the sameAkira Hatanaka2015-04-131-4/+6
| | | | | | | | target-cpu and target-features attribute strings as the caller. Differential Revision: http://reviews.llvm.org/D8984 llvm-svn: 234773
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-112-3/+3
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* [CallSite] Make construction from Value* (or Instruction*) explicit.Benjamin Kramer2015-04-106-6/+6
| | | | | | | | | | | | | | | | | | | CallSite roughly behaves as a common base CallInst and InvokeInst. Bring the behavior closer to that model by making upcasts explicit. Downcasts remain implicit and work as before. Following dyn_cast as a mental model checking whether a Value *V isa CallSite now looks like this: if (auto CS = CallSite(V)) // think dyn_cast instead of: if (CallSite CS = V) This is an extra token but I think it is slightly clearer. Making the ctor explicit has the advantage of not accidentally creating nullptr CallSites, e.g. when you pass a Value * to a function taking a CallSite argument. llvm-svn: 234601
* Reduce dyn_cast<> to isa<> or cast<> where possible.Benjamin Kramer2015-04-101-3/+2
| | | | | | No functional change intended. llvm-svn: 234586
* Divergence analysis for GPU programsJingyue Wu2015-04-104-0/+343
| | | | | | | | | | | | | | | | | | | Summary: Some optimizations such as jump threading and loop unswitching can negatively affect performance when applied to divergent branches. The divergence analysis added in this patch conservatively estimates which branches in a GPU program can diverge. This information can then help LLVM to run certain optimizations selectively. Test Plan: test/Analysis/DivergenceAnalysis/NVPTX/diverge.ll Reviewers: resistor, hfinkel, eliben, meheff, jholewinski Subscribers: broune, bjarke.roune, madhur13490, tstellarAMD, dberlin, echristo, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D8576 llvm-svn: 234567
* [LoopAccesses] Allow analysis to complete in the presence of uniform storesAdam Nemet2015-04-081-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (Re-apply r234361 with a fix and a testcase for PR23157) Both run-time pointer checking and the dependence analysis are capable of dealing with uniform addresses. I.e. it's really just an orthogonal property of the loop that the analysis computes. Run-time pointer checking will only try to reason about SCEVAddRec pointers or else gives up. If the uniform pointer turns out the be a SCEVAddRec in an outer loop, the run-time checks generated will be correct (start and end bounds would be equal). In case of the dependence analysis, we work again with SCEVs. When compared against a loop-dependent address of the same underlying object, the difference of the two SCEVs won't be constant. This will result in returning an Unknown dependence for the pair. When compared against another uniform access, the difference would be constant and we should return the right type of dependence (forward/backward/etc). The changes also adds support to query this property of the loop and modify the vectorizer to use this. Patch by Ashutosh Nema! llvm-svn: 234424
* Revert "[LoopAccesses] Allow analysis to complete in the presence of uniform ↵Adam Nemet2015-04-081-8/+11
| | | | | | | | | | stores" This reverts commit r234361. It caused PR23157. llvm-svn: 234387
* [LoopAccesses] Allow analysis to complete in the presence of uniform storesAdam Nemet2015-04-071-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Both run-time pointer checking and the dependence analysis are capable of dealing with uniform addresses. I.e. it's really just an orthogonal property of the loop that the analysis computes. Run-time pointer checking will only try to reason about SCEVAddRec pointers or else gives up. If the uniform pointer turns out the be a SCEVAddRec in an outer loop, the run-time checks generated will be correct (start and end bounds would be equal). In case of the dependence analysis, we work again with SCEVs. When compared against a loop-dependent address of the same underlying object, the difference of the two SCEVs won't be constant. This will result in returning an Unknown dependence for the pair. When compared against another uniform access, the difference would be constant and we should return the right type of dependence (forward/backward/etc). The changes also adds support to query this property of the loop and modify the vectorizer to use this. Patch by Ashutosh Nema! llvm-svn: 234361
* [LoopAccesses] New API to query if memchecks are necessary after partitioningAdam Nemet2015-04-071-0/+11
| | | | | | This is used by Loop Distribution. llvm-svn: 234283
* Transforms: Stop using DIDescriptor::is*() and auto-castingDuncan P. N. Exon Smith2015-04-061-4/+2
| | | | | | Same as r234255, but for lib/Analysis and lib/Transforms. llvm-svn: 234257
* [opaque pointer type] More GEP API migrations in IRBuilder usesDavid Blaikie2015-04-031-1/+1
| | | | | | | | | | | | | The plan here is to push the API changes out from the common components (like Constant::getGetElementPtr and IRBuilder::CreateGEP related functions) and just update callers to either pass the type if it's obvious, or pass null. Do this with LoadInst as well and anything else that comes up, then to start porting specific uses to not pass null anymore - this may require some refactoring in each case. llvm-svn: 234042
* [opaque pointer type] API migration for GEP constant factoriesDavid Blaikie2015-04-024-21/+29
| | | | | | | | | | | | | Require the pointee type to be passed explicitly and assert that it is correct. For now it's possible to pass nullptr here (and I've done so in a few places in this patch) but eventually that will be disallowed once all clients have been updated or removed. It'll be a long road to get all the way there... but if you have the cahnce to update your callers to pass the type explicitly without depending on a pointer's element type, that would be a good thing to do soon and a necessary thing to do eventually. llvm-svn: 233938
* [LoopAccesses] Handle case when no memchecks are needed after partitioningAdam Nemet2015-04-021-2/+4
| | | | llvm-svn: 233930
* [SCEV] Look at backedge dominating conditions (re-land r233447).Sanjoy Das2015-04-011-2/+62
| | | | | | | | | | | | | Summary: This change teaches ScalarEvolution::isLoopBackedgeGuardedByCond to look at edges within the loop body that dominate the latch. We don't do an exhaustive search for all possible edges, but only a quick walk up the dom tree. This re-lands r233447. r233447 was reverted because it caused massive compile-time regressions. This change has a fix for the same issue. llvm-svn: 233829
* Remove 4,096 loop scale limitation.Diego Novillo2015-04-011-21/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part 1 of fixes to address the problems described in https://llvm.org/bugs/show_bug.cgi?id=22719. The restriction to limit loop scales to 4,096 does not really prevent overflows anymore, as the underlying algorithm has changed and does not seem to suffer from this problem. Additionally, artificially restricting loop scales to such a low number skews frequency information, making loops of equal hotness appear to have very different hotness properties. The only loops that are artificially restricted to a scale of 4096 are infinite loops (those loops with an exit mass of 0). This prevents infinite loops from skewing the frequencies of other regions in the CFG. At the end of propagation, frequencies are scaled to values that take no more than 64 bits to represent. When the range of frequencies to be represented fits within 61 bits, it pushes up the scaling factor to a minimum of 8 to better distinguish small frequency values. Otherwise, small frequency values are all saturated down at 1. Tested on x86_64. Reviewers: dexonsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8718 llvm-svn: 233826
* [WinEH] Run cleanup handlers when an exception is thrownDavid Majnemer2015-03-301-3/+1
| | | | | | | | Generate tables in the .xdata section representing what actions to take when an exception is thrown. This currently fills in state for cleanups, catch handlers are still unfinished. llvm-svn: 233636
* [opaque pointer type] Change GetElementPtrInst::getIndexedType to take the ↵David Blaikie2015-03-303-5/+7
| | | | | | | | | | pointee type This pushes the use of PointerType::getElementType up into several callers - I'll essentially just have to keep pushing that up the stack until I can eliminate every call to it... llvm-svn: 233604
* Revert "[SCEV] Look at backedge dominating conditions."Daniel Jasper2015-03-301-40/+0
| | | | | | | This leads to terribly slow compile times under MSAN. More discussion on the commit thread of r233447. llvm-svn: 233529
* [SCEV] Look at backedge dominating conditions.Sanjoy Das2015-03-271-0/+40
| | | | | | | | | | | | | | | | Summary: This change teaches ScalarEvolution::isLoopBackedgeGuardedByCond to look at edges within the loop body that dominate the latch. We don't do an exhaustive search for all possible edges, but only a quick walk up the dom tree. Reviewers: atrick, hfinkel Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8627 llvm-svn: 233447
* Remove superfluous .str() and replace std::string concatenation with Twine.Yaron Keren2015-03-272-3/+3
| | | | llvm-svn: 233392
* [SCEV] Revert bailout added in r75511.Sanjoy Das2015-03-261-12/+11
| | | | | | | | | | | | | | Summary: With the introduction of MarkPendingLoopPredicates in r157092, I don't think the bailout is needed anymore. Reviewers: atrick, nicholas Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8624 llvm-svn: 233296
* [ValueTracking] Fix PR23011.Sanjoy Das2015-03-251-7/+16
| | | | | | | | | | | | | | Summary: `ComputeNumSignBits` returns incorrect results for `srem` instructions. This change fixes the issue and adds a test case. Reviewers: nadav, nicholas, atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8600 llvm-svn: 233225
* [APInt] Add an isSplat helper and use it in some places.Benjamin Kramer2015-03-251-3/+1
| | | | | | | To complement getSplat. This is more general than the binary decomposition method as it also handles non-pow2 splat sizes. llvm-svn: 233195
* !invariant.load semantics with potentially clobbering callsPhilip Reames2015-03-241-0/+9
| | | | | | | | | | A load from an invariant location is assumed to not alias any otherwise potentially aliasing stores. Our implementation only applied this rule to store instructions themselves whereas they it should apply for any memory accessing instruction. This results in both FRE and PRE becoming more effective at eliminating invariant loads. Note that as a follow on change I will likely move this into AliasAnalysis itself. That's where the TBAA constant flag is handled and the semantics are essentially the same. I'd like to separate the semantic change from the refactoring and thus have extended the hack that's already in MemoryDependenceAnalysis for this change. Differential Revision: http://reviews.llvm.org/D8591 llvm-svn: 233140
* Opaque Pointer Types: GEP API migrations to specify the gep type explicitlyDavid Blaikie2015-03-241-2/+3
| | | | | | | | | | | | | | | | | | | | | The changes to InstCombine (& SCEV) do seem a bit silly - it doesn't make anything obviously better to have the caller access the pointers element type (the thing I'm trying to remove) than the GEP itself, but it's a helpful migration step. This will allow me to more obviously lock down GEP (& Load, etc) API usage, then fix all the code that accesses pointer element types except the places that need to be removed (most of the InstCombines) anyway - at which point I'll need to just remove all that code because it won't be meaningful anymore (there will be no pointer types, so no bitcasts to combine) SCEV looks like it'll need some restructuring - we'll have to do a bit more work for GEP canonicalization, since it'll depend on how it's used if we can even manage to canonicalize it to a non-ugly GEP. I guess we can do some fun stuff like voting (do 2 out of 3 load from the GEP with a certain type that gives a pretty GEP? Does every typed use of the GEP use either a specific type or a generic type (i8*, etc)?) llvm-svn: 233131
* Refactor: Simplify boolean expressions in lib/AnalysisDavid Blaikie2015-03-241-6/+3
| | | | | | | | | | | | Simplify boolean expressions using `true` and `false` with `clang-tidy` Patch by Richard Thomson. Reviewed By: nlewycky Differential Revision: http://reviews.llvm.org/D8528 llvm-svn: 233091
* Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.Benjamin Kramer2015-03-236-2/+8
| | | | llvm-svn: 232998
* Purge unused includes throughout libSupport.Benjamin Kramer2015-03-232-0/+2
| | | | | | NFC. llvm-svn: 232976
* ValueTracking: Forward getConstantStringInfo's TrimAtNul param into ↵Benjamin Kramer2015-03-211-2/+3
| | | | | | | | | | | recursive invocation Currently this is only used to tweak the backend's memcpy inlining heuristics, testing that isn't very helpful. A real test case will follow in the next commit, where this behavior would cause a real miscompilation. llvm-svn: 232895
* MemoryDependenceAnalysis: Don't miscompile atomicsDavid Majnemer2015-03-211-11/+4
| | | | | | | | | | | | r216771 introduced a change to MemoryDependenceAnalysis that allowed it to reason about acquire/release operations. However, this change does not ensure that the acquire/release operations pair. Unfortunately, this leads to miscompiles as we won't see an acquire load as properly memory effecting. This largely reverts r216771. This fixes PR22708. llvm-svn: 232889
OpenPOWER on IntegriCloud