summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Value.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* NFC. Move getAlignment helper function from ValueTracking to Value class. Artur Pilipenko2016-02-241-0/+42
| | | | | | | | Reviewed By: reames, hfinkel Differential Revision: http://reviews.llvm.org/D16144 llvm-svn: 261735
* Simplify handleOperandChangeImpl() removing last argument (NFC)Mehdi Amini2016-02-101-1/+1
| | | | | | | | | | The Use argument was used to compute the operand number for a fast path when replacing only one operand. However we always have to go through all the operands. So the argument number can be recomputed locally anyway. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 260454
* Address NDEBUG-related linkage issues for Value::assertModuleIsMaterialized()Todd Fiala2016-02-031-1/+3
| | | | | | | | | | | | | | The IR/Value class had a linkage issue present when LLVM was built as a library, and the LLVM library build time had different settings for NDEBUG than the client of the LLVM library. Clients could get into a state where the LLVM lib expected Value::assertModuleIsMaterialized() to be inline-defined in the header but clients expected that method to be defined in the LLVM library. See this llvm-commits thread for more details: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160201/329667.html llvm-svn: 259695
* Fix Clang-tidy readability-redundant-control-flow warnings; other minor fixes.Eugene Zelenko2016-02-021-5/+3
| | | | | | Differential revision: http://reviews.llvm.org/D16793 llvm-svn: 259539
* Bring back "Assert that we have all use/users in the getters."Rafael Espindola2016-01-151-0/+10
| | | | | | | | | | | | | | | | | | | | | | This reverts commit r257751, bringing back r256105. The problem the assert found was fixed in r257915. Original commit message: Assert that we have all use/users in the getters. An error that is pretty easy to make is to use the lazy bitcode reader and then do something like if (V.use_empty()) The problem is that uses in unmaterialized functions are not accounted for. This patch adds asserts that all uses are known. llvm-svn: 257920
* Revert "Assert that we have all use/users in the getters."Michael Zolotukhin2016-01-141-10/+0
| | | | | | This reverts commit fdb838f3f8a8b6896bbbd5285555874eb3b748eb. llvm-svn: 257751
* Assert that we have all use/users in the getters.Rafael Espindola2015-12-191-0/+10
| | | | | | | | | | | | | | An error that is pretty easy to make is to use the lazy bitcode reader and then do something like if (V.use_empty()) The problem is that uses in unmaterialized functions are not accounted for. This patch adds asserts that all uses are known. llvm-svn: 256105
* Remove handling of AddrSpaceCast in stripAndAccumulateInBoundsConstantOffsetsPhilip Reames2015-09-231-2/+1
| | | | | | | | | | Patch by: simoncook Unlike BitCasts, AddrSpaceCasts do not always produce an output the same size as its input, which was previously assumed. This fixes cases where two address spaces do not have the same size pointer, as an assertion failure would occur when trying to prove deferenceability. LoopUnswitch is used in the particular test, but LICM also exhibits the same problem. Differential Revision: http://reviews.llvm.org/D13008 llvm-svn: 248422
* [IR] Switch static const to an enum to silence MSVC linker warningsDavid Majnemer2015-07-101-2/+0
| | | | | | | Integral class statics are handled oddly in MSVC, we don't need them in this case, use an enum instead. llvm-svn: 241958
* Devirtualize Constant::replaceUsesOfWithOnConstant.Pete Cooper2015-06-241-1/+1
| | | | | | | | | | | | | | | | | | | | This is part of the work to devirtualize Value. The old pattern was to call replaceUsesOfWithOnConstant which was overridden by subclasses. Those could then call replaceUsesOfWithOnConstantImpl on Constant to handle deleting the current value. To be consistent with other parts of the code, this has been changed so that we call the method on Constant, and that dispatches to an Impl on subclasses. As part of this, it made sense to rename the methods to be more descriptive. The new name is Constant::handleOperandChange, and it requires that all subclasses of Constant implement handleOperandChangeImpl, even if they just throw an error if they shouldn't be called. Reviewed by Duncan Exon Smith. llvm-svn: 240567
* Rename NumOperands to make it clear its managed by the User. NFC.Pete Cooper2015-06-121-1/+2
| | | | | | | | | | | | | | | | | | | | | This is to try make it very clear that subclasses shouldn't be changing the value directly. Now that OperandList for normal instructions is computed using the NumOperands, its critical that the NumOperands is accurate or we could compute the wrong offset to the first operand. I looked over all places which update NumOperands and they are all safe. Hung off use User's don't use NumOperands to compute the OperandList so they are safe to continue to manipulate it. The only other User which changed it was GlobalVariable which has an optional init list but always allocated space for a single Use. It was correctly setting NumOperands to 1 before setting an initializer, and setting it to 0 after clearing the init list, so the order was safe. Added some comments to that code to make sure that this isn't changed in future without being aware of this constraint. Reviewed by Duncan Exon Smith. llvm-svn: 239621
* Move the name pointer out of Value into a map that lives on theOwen Anderson2015-06-011-3/+32
| | | | | | | | | | | | | | | | LLVMContext. Production builds of clang do not set names on most Value's, so this is wasted space on almost all subclasses of Value. This reduces the size of all Value subclasses by 8 bytes on 64 bit hosts. The one tricky part of this change is averting compile time regression by keeping Value::hasName() fast. This required stealing bits out of NumOperands. With this change, peak memory usage on verify-uselistorder-nodbg.lto.bc is decreased by approximately 2.3% (~3MB absolute on my machine). llvm-svn: 238791
* Store intrinsic ID by value in Function instead of a string lookup. NFC.Pete Cooper2015-05-191-4/+7
| | | | | | | | | | | | On 64-bit targets, Function has 4-bytes of padding in its struct layout. This uses the space for the intrinsic ID. It is set and recalculated whenever the function name is set. This is similar to the current behavior which clears the function from the intrinsic ID cache when its renamed. The intrinsic cache itself is removed as the only purpose was to speedup calls to getIntrinsicID() which now just reading the new field in the struct. Reviewed by Duncan. http://reviews.llvm.org/D9836 llvm-svn: 237642
* Move Value.isDereferenceablePointer to ValueTracking [NFC]Philip Reames2015-04-231-131/+0
| | | | | | | | | | | Move isDereferenceablePointer function to Analysis. This function recursively tracks dereferencability over a chain of values like other functions in ValueTracking. This refactoring is motivated by further changes to support dereferenceable_or_null attribute (http://reviews.llvm.org/D8650). isDereferenceablePointer will be extended to perform context-sensitive analysis and IR is not a good place to have such functionality. Patch by: Artur Pilipenko <apilipenko@azulsystems.com> Differential Revision: reviews.llvm.org/D9075 llvm-svn: 235611
* [CallSite] Make construction from Value* (or Instruction*) explicit.Benjamin Kramer2015-04-101-2/+2
| | | | | | | | | | | | | | | | | | | 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
* Re-sort includes with sort-includes.py and insert raw_ostream.h where it's used.Benjamin Kramer2015-03-231-0/+1
| | | | llvm-svn: 232998
* Fix Value dangling reference debug outputAndrew Kaylor2015-03-101-6/+4
| | | | llvm-svn: 231889
* DataLayout is mandatory, update the API to reflect it with references.Mehdi Amini2015-03-101-19/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the DataLayout is a mandatory part of the module, let's start cleaning the codebase. This patch is a first attempt at doing that. This patch is not exactly NFC as for instance some places were passing a nullptr instead of the DataLayout, possibly just because there was a default value on the DataLayout argument to many functions in the API. Even though it is not purely NFC, there is no change in the validation. I turned as many pointer to DataLayout to references, this helped figuring out all the places where a nullptr could come up. I had initially a local version of this patch broken into over 30 independant, commits but some later commit were cleaning the API and touching part of the code modified in the previous commits, so it seemed cleaner without the intermediate state. Test Plan: Reviewers: echristo Subscribers: llvm-commits From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 231740
* isDereferenceablePointer: look through gc.relocate callsRamkumar Ramachandra2015-02-091-0/+9
| | | | | | | | | | While a theoretical GC might change dereferenceability on collection, there is no such known collector and no need to account for the case with a flag yet. Differential Revision: http://reviews.llvm.org/D7454 llvm-svn: 228606
* Teach isDereferenceablePointer() to look through bitcast constant expressions.Michael Kuperstein2015-02-051-1/+1
| | | | | | | | This fixes a LICM regression due to the new load+store pair canonicalization. Differential Revision: http://reviews.llvm.org/D7411 llvm-svn: 228284
* Cleaup ValueHandle to no longer keep a PointerIntPair for the Value*.Chandler Carruth2015-01-091-12/+12
| | | | | | | | This was used previously for metadata but is no longer needed there. Not doing this simplifies ValueHandle and will make it easier to fix things like AssertingVH's DenseMapInfo. llvm-svn: 225487
* The leak detector is dead, long live asan and valgrind.Rafael Espindola2014-12-221-4/+0
| | | | | | | In resent times asan and valgrind have found way more memory management bugs in llvm than the special purpose leak detector. llvm-svn: 224703
* IR: Split Metadata from ValueDuncan P. N. Exon Smith2014-12-091-36/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [InstCombine] Re-commit of r218721 (Optimize icmp-select-icmp sequence)Gerolf Hoflehner2014-11-211-0/+22
| | | | | | | Fixes the self-host fail. Note that this commit activates dominator analysis in the combiner by default (like the original commit did). llvm-svn: 222590
* Update SetVector to rely on the underlying set's insert to return a ↵David Blaikie2014-11-191-4/+4
| | | | | | | | | | | | | 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
* Assert that ValueHandleBase::ValueIsRAUWd doesn't change the tracked Value type.Frederic Riss2014-10-231-0/+2
| | | | | | | | | | | This invariant is enforced in Value::replaceAllUsesWith, thus it seems logical to apply it also to ValueHandles. This commit fixes InstCombine to not trigger the assertion during the removal of constant bitcasts in call instructions. Differential Revision: http://reviews.llvm.org/D5828 llvm-svn: 220468
* IR: Move NumOperands from User to Value, NFCDuncan P. N. Exon Smith2014-10-151-1/+2
| | | | | | | | | | | | | | | | | | Store `User::NumOperands` (and `MDNode::NumOperands`) in `Value`. On 64-bit host architectures, this reduces `sizeof(User)` and all subclasses by 8, and has no effect on `sizeof(Value)` (or, incidentally, on `sizeof(MDNode)`). On 32-bit host architectures, this increases `sizeof(Value)` by 4. However, it has no effect on `sizeof(User)` and `sizeof(MDNode)`, so the only concrete subclasses of `Value` that actually see the increase are `BasicBlock`, `Argument`, `InlineAsm`, and `MDString`. Moreover, I'll be shocked and confused if this causes a tangible memory regression. This has no functionality change (other than memory footprint). llvm-svn: 219845
* IR: Cleanup comments for Value, User, and MDNodeDuncan P. N. Exon Smith2014-10-151-26/+4
| | | | | | | | | | | | | A follow-up commit will modify the memory-layout of `Value`, `User`, and `MDNode`. First fix the comments to be doxygen-friendly (and to follow the coding standards). - Use "\brief" instead of "repeatedName -". - Add a brief intro where it was missing. - Remove duplicated comments from source files (and a couple of noisy/trivial comments altogether). llvm-svn: 219844
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-211-2/+2
| | | | | | needing to mention the size. llvm-svn: 216158
* Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to ↵Craig Topper2014-08-181-2/+2
| | | | | | | | avoid needing to mention the size." Getting a weird buildbot failure that I need to investigate. llvm-svn: 215870
* Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid ↵Craig Topper2014-08-171-2/+2
| | | | | | needing to mention the size. llvm-svn: 215868
* IR: Add Value::reverseUseList()Duncan P. N. Exon Smith2014-08-011-0/+19
| | | | | | I'm going to use this to improve `verify-uselistorder`. Part of PR5680. llvm-svn: 214594
* Handle AddrSpaceCast in stripAndAccumulateInBoundsConstantOffsetsHal Finkel2014-07-191-1/+2
| | | | | | | | All of the other similar functions in that part of the file look through addrspacecast in addition to bitcast, and I see no reason why stripAndAccumulateInBoundsConstantOffsets shouldn't do so also. llvm-svn: 213449
* Make Value::isDereferenceablePointer handle offsets to pointer types with ↵Hal Finkel2014-07-191-0/+21
| | | | | | | | | | | | | | | | | | dereferenceable attributes When we have a parameter (or call site return) with a dereferenceable attribute, it can specify the size of an array pointed to by that parameter. If we have a value for which we can accumulate a constant offset to such a parameter, then we can use that offset in a direct comparison with the size specified by the dereferenceable attribute. This enables us to handle cases like this: int foo(int a[static 3]) { return a[2]; /* this is always dereferenceable */ } llvm-svn: 213447
* Add a dereferenceable attributeHal Finkel2014-07-181-3/+24
| | | | | | | | | This attribute indicates that the parameter or return pointer is dereferenceable. Practically speaking, loads from such a pointer within the associated byte range are safe to speculatively execute. Such pointer parameters are common in source languages (C++ references, for example). llvm-svn: 213385
* Look through addrspacecast when checking isDereferenceablePointerMatt Arsenault2014-07-141-0/+3
| | | | llvm-svn: 212971
* Fix isDereferenceablePointer not to try to take the size of an unsized type.Hal Finkel2014-07-101-1/+2
| | | | | | I'll add a test-case shortly. llvm-svn: 212687
* Allow isDereferenceablePointer to look through some bitcastsHal Finkel2014-07-101-8/+23
| | | | | | | | | | | | | | | | isDereferenceablePointer should not give up upon encountering any bitcast. If we're casting from a pointer to a larger type to a pointer to a small type, we can continue by examining the bitcast's operand. This missing capability was noted in a comment in the function. In order for this to work, isDereferenceablePointer now takes an optional DataLayout pointer (essentially all callers already had such a pointer available). Most code uses isDereferenceablePointer though isSafeToSpeculativelyExecute (which already took an optional DataLayout pointer), and to enable the LICM test case, LICM needs to actually provide its DL pointer to isSafeToSpeculativelyExecute (which it was not doing previously). llvm-svn: 212686
* Convert StringMapEntry::Create to use StringRef instead of start/end ↵Craig Topper2014-06-111-1/+1
| | | | | | pointers. Simpliies all in tree call sites. No functional change. llvm-svn: 210638
* Reorder Value and User fields to save 8 bytes of padding on 64-bitReid Kleckner2014-06-091-4/+3
| | | | | | | | Reviewered by: rafael Differential Revision: http://reviews.llvm.org/D4073 llvm-svn: 210501
* Allow alias to point to an arbitrary ConstantExpr.Rafael Espindola2014-06-031-25/+0
| | | | | | | | | | | | | | | | | | | | | This patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is up to MC (or the system assembler) to decide if that expression is valid or not. This reduces our ability to diagnose invalid uses and how early we can spot them, but it also lets us do things like @test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32), i32 ptrtoint (i32* @bar to i32)) to i32*) An important implication of this patch is that the notion of aliased global doesn't exist any more. The alias has to encode the information needed to access it in its metadata (linkage, visibility, type, etc). Another consequence to notice is that getSection has to return a "const char *". It could return a NullTerminatedStringRef if there was such a thing, but when that was proposed the decision was to just uses "const char*" for that. llvm-svn: 210062
* Fix a warning in builds without asserts.Rafael Espindola2014-05-161-2/+1
| | | | llvm-svn: 209012
* Fix most of PR10367.Rafael Espindola2014-05-161-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the design of GlobalAlias so that it doesn't take a ConstantExpr anymore. It now points directly to a GlobalObject, but its type is independent of the aliasee type. To avoid changing all alias related tests in this patches, I kept the common syntax @foo = alias i32* @bar to mean the same as now. The cases that used to use cast now use the more general syntax @foo = alias i16, i32* @bar. Note that GlobalAlias now behaves a bit more like GlobalVariable. We know that its type is always a pointer, so we omit the '*'. For the bitcode, a nice surprise is that we were writing both identical types already, so the format change is minimal. Auto upgrade is handled by looking through the casts and no new fields are needed for now. New bitcode will simply have different types for Alias and Aliasee. One last interesting point in the patch is that replaceAllUsesWith becomes smart enough to avoid putting a ConstantExpr in the aliasee. This seems better than checking and updating every caller. A followup patch will delete getAliasedGlobal now that it is redundant. Another patch will add support for an explicit offset. llvm-svn: 209007
* Assert that we don't RAUW a Constant with a ConstantExpr that contains it.Rafael Espindola2014-05-131-1/+36
| | | | | | | | We already had an assert for foo->RAUW(foo), but not for something like foo->RAUW(GEP(foo)) and would go in an infinite loop trying to apply the replacement. llvm-svn: 208663
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-2/+2
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* [C++11] More 'nullptr' conversion or in some cases just using a boolean ↵Craig Topper2014-04-091-9/+9
| | | | | | check instead of comparing to nullptr. llvm-svn: 205831
* [C++11] Add range based accessors for the Use-Def chain of a Value.Chandler Carruth2014-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires a number of steps. 1) Move value_use_iterator into the Value class as an implementation detail 2) Change it to actually be a *Use* iterator rather than a *User* iterator. 3) Add an adaptor which is a User iterator that always looks through the Use to the User. 4) Wrap these in Value::use_iterator and Value::user_iterator typedefs. 5) Add the range adaptors as Value::uses() and Value::users(). 6) Update *all* of the callers to correctly distinguish between whether they wanted a use_iterator (and to explicitly dig out the User when needed), or a user_iterator which makes the Use itself totally opaque. Because #6 requires churning essentially everything that walked the Use-Def chains, I went ahead and added all of the range adaptors and switched them to range-based loops where appropriate. Also because the renaming requires at least churning every line of code, it didn't make any sense to split these up into multiple commits -- all of which would touch all of the same lies of code. The result is still not quite optimal. The Value::use_iterator is a nice regular iterator, but Value::user_iterator is an iterator over User*s rather than over the User objects themselves. As a consequence, it fits a bit awkwardly into the range-based world and it has the weird extra-dereferencing 'operator->' that so many of our iterators have. I think this could be fixed by providing something which transforms a range of T&s into a range of T*s, but that *can* be separated into another patch, and it isn't yet 100% clear whether this is the right move. However, this change gets us most of the benefit and cleans up a substantial amount of code around Use and User. =] llvm-svn: 203364
* [Modules] Move the LeakDetector header into the IR library where theChandler Carruth2014-03-041-1/+1
| | | | | | | | | | | source file had already been moved. Also move the unittest into the IR unittest library. This may seem an odd thing to put in the IR library but we only really use this with instructions and it needs the LLVM context to work, so it is intrinsically tied to the IR library. llvm-svn: 202842
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-041-1/+1
| | | | | | | | | | | Move the test for this class into the IR unittests as well. This uncovers that ValueMap too is in the IR library. Ironically, the unittest for ValueMap is useless in the Support library (honestly, so was the ValueHandle test) and so it already lives in the IR unittests. Mmmm, tasty layering. llvm-svn: 202821
* [Modules] Move GetElementPtrTypeIterator into the IR library. As itsChandler Carruth2014-03-041-1/+1
| | | | | | | | | name might indicate, it is an iterator over the types in an instruction in the IR.... You see where this is going. Another step of modularizing the support library. llvm-svn: 202815
OpenPOWER on IntegriCloud