summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Analysis/CFLAliasAnalysis.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [CFLAA] Split into Anders+Steens analysis.George Burgess IV2016-07-061-1145/+0
| | | | | | | | | | | | | | | | | | | | | StratifiedSets (as implemented) is very fast, but its accuracy is also limited. If we take a more aggressive andersens-like approach, we can be way more accurate, but we'll also end up being slower. So, we've decided to split CFLAA into CFLSteensAA and CFLAndersAA. Long-term, we want to end up in a place where CFLSteens is queried first; if it can provide an answer, great (since queries are basically map lookups). Otherwise, we'll fall back to CFLAnders, BasicAA, etc. This patch splits everything out so we can try to do something like that when we get a reasonable CFLAnders implementation. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21910 llvm-svn: 274589
* [CFLAA] Add support for ModRef queries.George Burgess IV2016-06-301-0/+71
| | | | | | | | | | | | This patch makes CFLAA answer some ModRef queries. Because we don't distinguish between reading/writing when making StratifiedSets, we're unable to offer any of the readonly-related answers. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21858 llvm-svn: 274197
* [CFLAA] Make MSVC happy. NFC.George Burgess IV2016-06-271-1/+3
| | | | | | | | Apparently, MSVC complains if there's an implicit conversion from `unsigned` to `unsigned long long`, if the `unsigned` is the result of a bit shift. llvm-svn: 273955
* [CFLAA] Use unsigned numbers for bit-shifts.George Burgess IV2016-06-271-1/+1
| | | | | | | | | This uses `1U` instead of `1ULL` because StratifiedAttrs is a 32-bit bitset. Thanks to Hans-Bernhard Broker for bringing this up. llvm-svn: 273902
* Attempt to fix MSVC breakage caused by r273636.George Burgess IV2016-06-241-9/+13
| | | | | | Apparently earlier versions of MSVC don't have constexpr bitset ctors. llvm-svn: 273637
* [CFLAA] Propagate StratifiedAttrs in interproc. analysis.George Burgess IV2016-06-241-48/+113
| | | | | | | | | | | | | | | | | This patch also has a refactor that kills StratifiedAttr, and leaves us with StratifiedAttrs, because having both was mildly redundant. This patch makes us correctly handle stratified attributes when doing interprocedural analysis. It also adds another attribute, AttrCaller, which acts like AttrUnknown. We can filter out AttrCaller values when during interprocedural analysis, since the caller should have information about what arguments it's passing to its callee. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21645 llvm-svn: 273636
* Attempt #2 to unbreak bots broken by r273596.George Burgess IV2016-06-231-2/+2
| | | | | | | | Some of the bots running GCC 4.7 seem to be having trouble with lambdas that explicitly capture `this`. Relevant-looking bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 llvm-svn: 273613
* Attempt to fix breakage caused by r273596.George Burgess IV2016-06-231-3/+3
| | | | llvm-svn: 273601
* [CFLAA] Use better interprocedural function summaries.George Burgess IV2016-06-231-92/+110
| | | | | | | | | | | | | Previously, we just unified any arguments that seemed to be related to each other. With this patch, we now respect dereference levels, etc. which should make us substantially more accurate. Proper handling of StratifiedAttrs will be done in a later patch. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21536 llvm-svn: 273596
* [CFLAA] Be more aggressive with interprocedural analysis.George Burgess IV2016-06-211-1/+1
| | | | | | | | | | | | | This patch makes us perform interprocedural analysis on functions that don't have internal linkage. It also removes a test that should've been deleted in an earlier commit (since other tests now cover everything that the newly-removed test covers). Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21513 llvm-svn: 273229
* Attempt to make MSVC buildbots happy.George Burgess IV2016-06-201-3/+1
| | | | | | Broken by r273219. llvm-svn: 273220
* [CFLAA] Add interprocedural function summaries.George Burgess IV2016-06-201-141/+154
| | | | | | | | | | | | | This patch adds function summaries, so that we don't need to recompute various properties about function parameters/return values at each callsite of a function. It also adds many interprocedural tests for CFLAA. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21475#inline-182390 llvm-svn: 273219
* [CFLAA] Ignore non-pointers, move Attrs to graph nodes.George Burgess IV2016-06-151-64/+93
| | | | | | | | | | | | | | This patch makes CFLAA ignore non-pointer values, since we can now sanely do that with the escaping/unknown attributes. Additionally, StratifiedAttrs make more sense to sit on nodes than edges (since they're properties of values, and ultimately end up on the nodes of StratifiedSets). So, this patch puts said attributes on nodes. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21387 llvm-svn: 272833
* [CFLAA] Tag arguments as escaped instead of unknown.George Burgess IV2016-06-141-305/+216
| | | | | | | | | | | | | | | | | | | This patch also includes some refactoring. Prior to this patch, we tagged all CFLAA attributes as unknown. This is suboptimal, since it meant that any Value used as an argument would be considered to alias any other Value that existed. Now that we have the machinery to tag sets below the set for an arbitrary value with attributes, it's okay to be less conservative with arguments. (Specifically, we still tag the set under an argument with unknown). Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21262 llvm-svn: 272690
* [CFLAA] Refactor graph-building code. NFC.George Burgess IV2016-06-141-170/+160
| | | | | | | | | | | This patch refactors CFLAA's graph building code. This makes keeping track of common state (TargetLibraryInfo, ...) easier. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21261 llvm-svn: 272688
* Attempt to make windows buildbots happy.George Burgess IV2016-06-131-4/+0
| | | | | | | Broken by r272578. I didn't realize that the default move ctor complaints would happen for non-template classes. :) llvm-svn: 272579
* [CFLAA] Refactor to remove redundant maps. NFC.George Burgess IV2016-06-131-209/+104
| | | | | | | | Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21233 llvm-svn: 272578
* [CFLAA] Handle global/arg attrs more sanely.George Burgess IV2016-06-091-20/+29
| | | | | | | | | | | | | | | | Prior to this patch, we used argument/global stratified attributes in order to note that a value could have come from either dereferencing a global/arg, or from the assignment from a global/arg. Now, AttrUnknown is placed on sets when we see a dereference, instead of the global/arg attributes. This allows us to be more aggressive in the future when we see global/arg attributes without AttrUnknown. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21110 llvm-svn: 272335
* [CFLAA] Add AttrEscaped, remove bit twiddling functions.George Burgess IV2016-06-071-49/+58
| | | | | | | | | | | | | | | | | | | | | This patch does a few things: - Unifies AttrAll and AttrUnknown (since they were used for more or less the same purpose anyway). - Introduces AttrEscaped, an attribute that notes that a value escapes our analysis for a given set, but not that an unknown value flows into said set. - Removes functions that take bit indices, since we also had functions that took bitsets, and the use of both (with similar names) was unclear and bug-prone. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21000 llvm-svn: 272040
* [CFLAA] Recognize builtin allocation functions.George Burgess IV2016-06-011-30/+55
| | | | | | | | | | | This patch extends CFLAA to recognize allocation functions such as malloc, free, etc, so we can treat them more aggressively. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D20776 llvm-svn: 271421
* [CFLAA] Don't link GEP pointers to GEP indices.George Burgess IV2016-05-311-2/+0
| | | | | | | | | | | | | | | | | Code like the following is considered broken, and doesn't need to be supported by our AA magicks: void getFoo(int *P) { int *PAlias = (int *)((char *)NULL + (uintptr_t)P); } This patch makes CFLAA drop support for code like this. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D20775 llvm-svn: 271322
* [CFLAA] Fix a use-of-invalid-pointer bug.George Burgess IV2016-05-021-1/+6
| | | | | | | | | | | | As shown in the diff, we used to add to CFLAA's cache by doing `Cache[Fn] = buildSetsFrom(Fn)`. `buildSetsFrom(Fn)` may cause `Cache` to reallocate its underlying storage, if this happens and `Cache[Fn]` was evaluated prior to `buildSetsFrom(Fn)`, then we'll store the result to a bad address. Patch by Jia Chen. llvm-svn: 268269
* [NFC] Header cleanupMehdi Amini2016-04-181-2/+0
| | | | | | | | | | | | | | Removed some unused headers, replaced some headers with forward class declarations. Found using simple scripts like this one: clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap' Patch by Eugene Kosov <claprix@yandex.ru> Differential Revision: http://reviews.llvm.org/D19219 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266595
* [CFLAA] Fix up code style a bit. NFC.George Burgess IV2016-04-131-125/+112
| | | | llvm-svn: 266262
* [CFLAA] Fix PR27213; incorrect tagging of args/globalsGeorge Burgess IV2016-04-051-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch, CFLAA wouldn't tag arguments/globals properly if it didn't find any "interesting" edges on them. This means that, if all you do is store constants to a global or argument, we would never actually treat it as a global/argument. Test case: define void @foo(i32* %A, i32* %B) #0 { entry: store i32 0, i32* %A, align 4 store i32 0, i32* %B, align 4 ret void } CFLAA would say that %A can't alias %B, because neither pointer was used in an interesting way. This patch makes us note whether something is an argument, global, ... regardless of how interesting CFLAA thinks its uses are. (For the record, using a value in an interesting way means loading from it, using it in a GEP, ...) llvm-svn: 265474
* IR: Introduce ConstantAggregate, NFCDuncan P. N. Exon Smith2016-04-051-4/+3
| | | | | | | | | | | | Add a common parent class for ConstantArray, ConstantVector, and ConstantStruct called ConstantAggregate. These are the aggregate subclasses of Constant that take operands. This is mainly a cleanup, adding common `isa` target and removing duplicated code. However, it also simplifies caching which constants point transitively at `GlobalValue` (a possible future direction). llvm-svn: 265466
* Rename DenseMap::resize() into DenseMap::reserve() (NFC)Mehdi Amini2016-03-221-1/+1
| | | | | | | This is more coherent with usual containers. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 264026
* [PM] Make the AnalysisManager parameter to run methods a reference.Chandler Carruth2016-03-111-1/+1
| | | | | | | | | | | | This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
* [PM] Implement the final conclusion as to how the analysis IDs shouldChandler Carruth2016-03-111-0/+2
| | | | | | | | | | | | | | | | | | | | work in the face of the limitations of DLLs and templated static variables. This requires passes that use the AnalysisBase mixin provide a static variable themselves. So as to keep their APIs clean, I've made these private and befriended the CRTP base class (which is the common practice). I've added documentation to AnalysisBase for why this is necessary and at what point we can go back to the much simpler system. This is clearly a better pattern than the extern template as it caught *numerous* places where the template magic hadn't been applied and things were "just working" but would eventually have broken mysteriously. llvm-svn: 263216
* [AA] Hoist the logic to reformulate various AA queries in terms of otherChandler Carruth2016-03-021-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parts of the AA interface out of the base class of every single AA result object. Because this logic reformulates the query in terms of some other aspect of the API, it would easily cause O(n^2) query patterns in alias analysis. These could in turn be magnified further based on the number of call arguments, and then further based on the number of AA queries made for a particular call. This ended up causing problems for Rust that were actually noticable enough to get a bug (PR26564) and probably other places as well. When originally re-working the AA infrastructure, the desire was to regularize the pattern of refinement without losing any generality. While I think it was successful, that is clearly proving to be too costly. And the cost is needless: we gain no actual improvement for this generality of making a direct query to tbaa actually be able to re-use some other alias analysis's refinement logic for one of the other APIs, or some such. In short, this is entirely wasted work. To the extent possible, delegation to other API surfaces should be done at the aggregation layer so that we can avoid re-walking the aggregation. In fact, this significantly simplifies the logic as we no longer need to smuggle the aggregation layer into each alias analysis (or the TargetLibraryInfo into each alias analysis just so we can form argument memory locations!). However, we also have some delegation logic inside of BasicAA and some of it even makes sense. When the delegation logic is baking in specific knowledge of aliasing properties of the LLVM IR, as opposed to simply reformulating the query to utilize a different alias analysis interface entry point, it makes a lot of sense to restrict that logic to a different layer such as BasicAA. So one aspect of the delegation that was in every AA base class is that when we don't have operand bundles, we re-use function AA results as a fallback for callsite alias results. This relies on the IR properties of calls and functions w.r.t. aliasing, and so seems a better fit to BasicAA. I've lifted the logic up to that point where it seems to be a natural fit. This still does a bit of redundant work (we query function attributes twice, once via the callsite and once via the function AA query) but it is *exactly* twice here, no more. The end result is that all of the delegation logic is hoisted out of the base class and into either the aggregation layer when it is a pure retargeting to a different API surface, or into BasicAA when it relies on the IR's aliasing properties. This should fix the quadratic query pattern reported in PR26564, although I don't have a stand-alone test case to reproduce it. It also seems general goodness. Now the numerous AAs that don't need target library info don't carry it around and depend on it. I think I can even rip out the general access to the aggregation layer and only expose that in BasicAA as it is the only place where we re-query in that manner. However, this is a non-trivial change to the AA infrastructure so I want to get some additional eyes on this before it lands. Sadly, it can't wait long because we should really cherry pick this into 3.8 if we're going to go this route. Differential Revision: http://reviews.llvm.org/D17329 llvm-svn: 262490
* [PM] Introduce CRTP mixin base classes to help define passes andChandler Carruth2016-02-261-2/+0
| | | | | | | | | | | | | | | | | analyses in the new pass manager. These just handle really basic stuff: turning a type name into a string statically that is nice to print in logs, and getting a static unique ID for each analysis. Sadly, the format of passes in anonymous namespaces makes using their names in tests really annoying so I've customized the names of the no-op passes to keep tests sane to read. This is the first of a few simplifying refactorings for the new pass manager that should reduce boilerplate and confusion. llvm-svn: 262004
* [PM/AA] Wire up CFLAA to the new pass manager fully, and port one of itsChandler Carruth2016-02-201-0/+1
| | | | | | | | | tests over to exercise this code. This uncovered a few missing bits here and there in the analysis, but nothing interesting. llvm-svn: 261404
* Minor style cleanup of CFLAA. NFC.George Burgess IV2016-01-281-6/+11
| | | | llvm-svn: 259008
* [PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatibleChandler Carruth2015-09-091-51/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with the new pass manager, and no longer relying on analysis groups. This builds essentially a ground-up new AA infrastructure stack for LLVM. The core ideas are the same that are used throughout the new pass manager: type erased polymorphism and direct composition. The design is as follows: - FunctionAAResults is a type-erasing alias analysis results aggregation interface to walk a single query across a range of results from different alias analyses. Currently this is function-specific as we always assume that aliasing queries are *within* a function. - AAResultBase is a CRTP utility providing stub implementations of various parts of the alias analysis result concept, notably in several cases in terms of other more general parts of the interface. This can be used to implement only a narrow part of the interface rather than the entire interface. This isn't really ideal, this logic should be hoisted into FunctionAAResults as currently it will cause a significant amount of redundant work, but it faithfully models the behavior of the prior infrastructure. - All the alias analysis passes are ported to be wrapper passes for the legacy PM and new-style analysis passes for the new PM with a shared result object. In some cases (most notably CFL), this is an extremely naive approach that we should revisit when we can specialize for the new pass manager. - BasicAA has been restructured to reflect that it is much more fundamentally a function analysis because it uses dominator trees and loop info that need to be constructed for each function. All of the references to getting alias analysis results have been updated to use the new aggregation interface. All the preservation and other pass management code has been updated accordingly. The way the FunctionAAResultsWrapperPass works is to detect the available alias analyses when run, and add them to the results object. This means that we should be able to continue to respect when various passes are added to the pipeline, for example adding CFL or adding TBAA passes should just cause their results to be available and to get folded into this. The exception to this rule is BasicAA which really needs to be a function pass due to using dominator trees and loop info. As a consequence, the FunctionAAResultsWrapperPass directly depends on BasicAA and always includes it in the aggregation. This has significant implications for preserving analyses. Generally, most passes shouldn't bother preserving FunctionAAResultsWrapperPass because rebuilding the results just updates the set of known AA passes. The exception to this rule are LoopPass instances which need to preserve all the function analyses that the loop pass manager will end up needing. This means preserving both BasicAAWrapperPass and the aggregating FunctionAAResultsWrapperPass. Now, when preserving an alias analysis, you do so by directly preserving that analysis. This is only necessary for non-immutable-pass-provided alias analyses though, and there are only three of interest: BasicAA, GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is preserved when needed because it (like DominatorTree and LoopInfo) is marked as a CFG-only pass. I've expanded GlobalsAA into the preserved set everywhere we previously were preserving all of AliasAnalysis, and I've added SCEVAA in the intersection of that with where we preserve SCEV itself. One significant challenge to all of this is that the CGSCC passes were actually using the alias analysis implementations by taking advantage of a pretty amazing set of loop holes in the old pass manager's analysis management code which allowed analysis groups to slide through in many cases. Moving away from analysis groups makes this problem much more obvious. To fix it, I've leveraged the flexibility the design of the new PM components provides to just directly construct the relevant alias analyses for the relevant functions in the IPO passes that need them. This is a bit hacky, but should go away with the new pass manager, and is already in many ways cleaner than the prior state. Another significant challenge is that various facilities of the old alias analysis infrastructure just don't fit any more. The most significant of these is the alias analysis 'counter' pass. That pass relied on the ability to snoop on AA queries at different points in the analysis group chain. Instead, I'm planning to build printing functionality directly into the aggregation layer. I've not included that in this patch merely to keep it smaller. Note that all of this needs a nearly complete rewrite of the AA documentation. I'm planning to do that, but I'd like to make sure the new design settles, and to flesh out a bit more of what it looks like in the new pass manager first. Differential Revision: http://reviews.llvm.org/D12080 llvm-svn: 247167
* Fix: CFLAA -- Mark no-args returns as unknownGeorge Burgess IV2015-08-281-0/+10
| | | | | | | | | | | | | | Prior to this patch, we hadn't been marking StratifiedSets with the appropriate StratifiedAttrs when handling the result of no-args call instructions. This caused us to report NoAlias when handed, for example, an escaped alloca and a result from an opaque function. Now we properly mark the return value of said functions. Thanks again to Chandler, Richard, and Nick for pinging me about this. Differential review: http://reviews.llvm.org/D12408 llvm-svn: 246240
* [PM/AA] Hoist the value handle definition for CFLAA into the header toChandler Carruth2015-08-141-22/+0
| | | | | | | satisfy libc++'s std::forward_list which requires the value type to be complete. llvm-svn: 245011
* [PM/AA] Extract a minimal interface for CFLAA to its own header file.Chandler Carruth2015-08-141-132/+78
| | | | | | | | | | I've used forward declarations and reorderd the source code some to make this reasonably clean and keep as much of the code as possible in the source file, including all the stratified set details. Just the basic AA interface and the create function are in the header file, and the header file is now included into the relevant locations. llvm-svn: 245009
* Fix some comment typos.Benjamin Kramer2015-08-081-2/+2
| | | | llvm-svn: 244402
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-031-3/+1
| | | | | | | | | | | | | | | | | | | | | | deprecated in C++11 Various value handles needed to be copy constructible and copy assignable (mostly for their use in DenseMap). But to avoid an API that might allow accidental slicing, make these members protected in the base class and make derived classes final (the special members become implicitly public there - but disallowing further derived classes that might be sliced to the intermediate type). Might be worth having a warning a bit like -Wnon-virtual-dtor that catches public move/copy assign/ctors in classes with virtual functions. (suppressable in the same way - by making them protected in the base, and making the derived classes final) Could be fancier and only diagnose them when they're actually called, potentially. Also allow a few default implementations where custom implementations (especially with non-standard return types) were implemented. llvm-svn: 243909
* Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)Alexander Kornienko2015-06-231-1/+1
| | | | | | Apparently, the style needs to be agreed upon first. llvm-svn: 240390
* [PM/AA] Hoist the AliasResult enum out of the AliasAnalysis class.Chandler Carruth2015-06-221-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow classes to implement the AA interface without deriving from the class or referencing an internal enum of some other class as their return types. Also, to a pretty fundamental extent, concepts such as 'NoAlias', 'MayAlias', and 'MustAlias' are first class concepts in LLVM and we aren't saving anything by scoping them heavily. My mild preference would have been to use a scoped enum, but that feature is essentially completely broken AFAICT. I'm extremely disappointed. For example, we cannot through any reasonable[1] means construct an enum class (or analog) which has scoped names but converts to a boolean in order to test for the possibility of aliasing. [1]: Richard Smith came up with a "solution", but it requires class templates, and lots of boilerplate setting up the enumeration multiple times. Something like Boost.PP could potentially bundle this up, but even that would be quite painful and it doesn't seem realistically worth it. The enum class solution would probably work without the need for a bool conversion. Differential Revision: http://reviews.llvm.org/D10495 llvm-svn: 240255
* Typo. NFC.Chad Rosier2015-06-191-2/+1
| | | | llvm-svn: 240141
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* [PM/AA] Remove the Location typedef from the AliasAnalysis class nowChandler Carruth2015-06-171-5/+5
| | | | | | | | | | | | 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
* Don't create instructions from ConstantExpr's in CFLAliasAnalysis.Pete Cooper2015-06-121-12/+41
| | | | | | | | | | The CFLAA code currently calls ConstantExpr::getAsInstruction which creates an instruction from a constant expr. We then pass that instruction to the InstVisitor to analyze it. Its not necessary to create these instructions as we can just cast from Constant to Operator in the visitor. This is how other InstVisitor’s such as SelectionDAGBuilder handle ConstantExpr. llvm-svn: 239616
* Convert PHI getIncomingValue() to foreach over incoming_values(). NFC.Pete Cooper2015-05-121-2/+1
| | | | | | | | We already had a method to iterate over all the incoming values of a PHI. This just changes all eligible code to use it. Ineligible code included anything which cared about the index, or was also trying to get the i'th incoming BB. llvm-svn: 237169
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-2/+2
| | | | | | | | | | | | | | 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
* Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.Benjamin Kramer2015-03-231-1/+2
| | | | llvm-svn: 232998
* Made CFLAA agree with clang-format. NFC.George Burgess IV2015-03-151-9/+7
| | | | | | So everyone's lives are easier in the future llvm-svn: 232293
* Added ConstantExpr support to CFLAA.George Burgess IV2015-03-101-40/+143
| | | | | | | | CFLAA didn't know how to properly handle ConstantExprs; it would silently ignore them. This was a problem if the ConstantExpr is, say, a GEP of a global, because CFLAA wouldn't realize that there's a global there. :) llvm-svn: 231743
OpenPOWER on IntegriCloud