summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Value.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Use Argument::hasAttribute and AttributeList::ReturnIndex moreReid Kleckner2017-04-281-2/+2
| | | | | | | | | | | This eliminates many extra 'Idx' induction variables in loops over arguments in CodeGen/ and Target/. It also reduces the number of places where we assume that ReturnIndex is 0 and that we should add one to argument numbers to get the corresponding attribute list index. NFC llvm-svn: 301666
* Use accessors for ValueHandleBase::V; NFCSanjoy Das2017-04-271-12/+12
| | | | | | | | | | | This changes code that touches ValueHandleBase::V to go through getValPtr and (newly added) setValPtr. This functionality will be used later, but also seemed like a generally good cleanup. I also renamed the field to Val, but that's just to make it obvious that I fixed all the uses. llvm-svn: 301518
* Reverts commit r301424, r301425 and r301426Sanjoy Das2017-04-261-14/+9
| | | | | | | | | | | | Commits were: "Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts" "Add a new WeakVH value handle; NFC" "Rename WeakVH to WeakTrackingVH; NFC" The changes assumed pointers are 8 byte aligned on all architectures. llvm-svn: 301429
* Add a new WeakVH value handle; NFCSanjoy Das2017-04-261-2/+5
| | | | | | | | | | | | | | Summary: WeakVH nulls itself out if the value it was tracking gets deleted, but it does not track RAUW. Reviewers: dblaikie, davide Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32267 llvm-svn: 301425
* Rename WeakVH to WeakTrackingVH; NFCSanjoy Das2017-04-261-9/+11
| | | | | | | | | | | | | | | | Summary: I plan to use WeakVH to mean "nulls itself out on deletion, but does not track RAUW" in a subsequent commit. Reviewers: dblaikie, davide Reviewed By: davide Subscribers: arsenm, mehdi_amini, mcrosier, mzolotukhin, jfb, llvm-commits, nhaehnle Differential Revision: https://reviews.llvm.org/D32266 llvm-svn: 301424
* Handle invariant.group.barrier in BasicAAPiotr Padlewski2017-04-241-2/+17
| | | | | | | | | | | | | | | | | | | | | Summary: llvm.invariant.group.barrier returns pointer that mustalias pointer it takes. It can't be marked with `returned` attribute, because it would be remove easily. The other reason is that only Alias Analysis can know about this, because if any other pass would know it, then the result would be replaced with it's argument, which would be invalid. We can think about returned pointer as something that mustalias, but it doesn't have to be bitwise the same as the argument. Reviewers: dberlin, chandlerc, hfinkel, sanjoy Subscribers: reames, nlewycky, rsmith, anna, amharc Differential Revision: https://reviews.llvm.org/D31585 llvm-svn: 301227
* [IR] Implement pairs of non-const and const methods using the const version ↵Craig Topper2017-03-271-21/+22
| | | | | | | | instead of the non-const version. NFCI This removes a const_cast of the this pointer. llvm-svn: 298831
* Rename AttributeSet to AttributeListReid Kleckner2017-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name. Rename AttributeSetImpl to AttributeListImpl to follow suit. It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value. Reviewers: sanjoy, javed.absar, chandlerc, pete Reviewed By: pete Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits Differential Revision: https://reviews.llvm.org/D31102 llvm-svn: 298393
* [IR] Don't call assertModuleIsMaterialized in release buildsCraig Topper2017-01-131-1/+1
| | | | | | | | | | | | | | | | | Summary: To fix a release vs debug build linking error, r259695 made the body of assertModuleIsMaterialized empty if Value.cpp gets compiled in a release build. This way any code compiled as a debug build can still link against a release version of the function. This patch takes this a step farther and removes all calls to it from Value.h in any code that includes it in a relase build. This shrinks the opt binary on my macbook build by 17240 bytes. Reviewers: rafael Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D28191 llvm-svn: 291883
* [BDCE] Skip metadata while replacing uses.Davide Italiano2016-12-071-2/+10
| | | | | | | | | | | | The fix committed in r288851 doesn't cover all the cases. In particular, if we have an instruction with side effects which has a no non-dbg use not depending on the bits, we still perform RAUW destroying the dbg.value's first argument. Prevent metadata from being replaced here to avoid the issue. Differential Revision: https://reviews.llvm.org/D27534 llvm-svn: 288987
* Don't create a SymbolTable in Function when the LLVMContext discards value ↵Mehdi Amini2016-09-171-3/+3
| | | | | | | | | | | | | | names (NFC) The ValueSymbolTable is used to detect name conflict and rename instructions automatically. This is not needed when the value names are automatically discarded by the LLVMContext. No functional change intended, just saving a little bit of memory. This is a recommit of r281806 after fixing the accessor to return a pointer instead of a reference and updating all the call-sites. llvm-svn: 281813
* Add an isSwiftError predicate to ValueArnold Schwaighofer2016-09-101-0/+10
| | | | llvm-svn: 281143
* Replace "fallthrough" comments with LLVM_FALLTHROUGHJustin Bogner2016-08-171-2/+2
| | | | | | | This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead. llvm-svn: 278902
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-121-2/+2
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* BasicAA should look through functions with returned argumentsHal Finkel2016-07-111-0/+12
| | | | | | | | | | | Motivated by the work on the llvm.noalias intrinsic, teach BasicAA to look through returned-argument functions when answering queries. This is essential so that we don't loose all other AA information when supplementing with llvm.noalias. Differential Revision: http://reviews.llvm.org/D9383 llvm-svn: 275035
* Remove Value::isPointerDereferenceable; NFCISanjoy Das2016-06-021-24/+18
| | | | | | | | ... and merge into `Value::getPointerDereferenceableBytes`. This was suggested by Artur Pilipenko in D20764 -- since we no longer allow loads of unsized types, there is no need anymore to have this special logic. llvm-svn: 271455
* NFC. Introduce Value::isPointerDereferenceableArtur Pilipenko2016-05-111-0/+23
| | | | | | | | | | Extract a part of isDereferenceableAndAlignedPointer functionality to Value: Reviewed By: hfinkel, sanjoy Differential Revision: http://reviews.llvm.org/D17611 llvm-svn: 269190
* NFC. Introduce Value::getPointerDerferecnceableBytesArtur Pilipenko2016-04-271-0/+34
| | | | | | | | | | Extract a part of isDereferenceableAndAlignedPointer functionality to Value::getPointerDerferecnceableBytes. Currently it's a NFC, but in future I'm going to accumulate all the logic about value dereferenceability in this function similarly to Value::getPointerAlignment function (D16144). Reviewed By: reames Differential Revision: http://reviews.llvm.org/D17572 llvm-svn: 267708
* Use DL preferred alignment for alloca in Value::getPointerAlignmentArtur Pilipenko2016-04-271-2/+7
| | | | | | | | | | Teach Value::getPointerAlignment that allocas with no explicit alignment are aligned to preferred alignment of the allocated type. Reviewed By: hfinkel Differential Revision: http://reviews.llvm.org/D17569 llvm-svn: 267689
* Don't IPO over functions that can be de-refinedSanjoy Das2016-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR26774. If you're aware of the issue, feel free to skip the "Motivation" section and jump directly to "This patch". Motivation: I define "refinement" as discarding behaviors from a program that the optimizer has license to discard. So transforming: ``` void f(unsigned x) { unsigned t = 5 / x; (void)t; } ``` to ``` void f(unsigned x) { } ``` is refinement, since the behavior went from "if x == 0 then undefined else nothing" to "nothing" (the optimizer has license to discard undefined behavior). Refinement is a fundamental aspect of many mid-level optimizations done by LLVM. For instance, transforming `x == (x + 1)` to `false` also involves refinement since the expression's value went from "if x is `undef` then { `true` or `false` } else { `false` }" to "`false`" (by definition, the optimizer has license to fold `undef` to any non-`undef` value). Unfortunately, refinement implies that the optimizer cannot assume that the implementation of a function it can see has all of the behavior an unoptimized or a differently optimized version of the same function can have. This is a problem for functions with comdat linkage, where a function can be replaced by an unoptimized or a differently optimized version of the same source level function. For instance, FunctionAttrs cannot assume a comdat function is actually `readnone` even if it does not have any loads or stores in it; since there may have been loads and stores in the "original function" that were refined out in the currently visible variant, and at the link step the linker may in fact choose an implementation with a load or a store. As an example, consider a function that does two atomic loads from the same memory location, and writes to memory only if the two values are not equal. The optimizer is allowed to refine this function by first CSE'ing the two loads, and the folding the comparision to always report that the two values are equal. Such a refined variant will look like it is `readonly`. However, the unoptimized version of the function can still write to memory (since the two loads //can// result in different values), and selecting the unoptimized version at link time will retroactively invalidate transforms we may have done under the assumption that the function does not write to memory. Note: this is not just a problem with atomics or with linking differently optimized object files. See PR26774 for more realistic examples that involved neither. This patch: This change introduces a new set of linkage types, predicated as `GlobalValue::mayBeDerefined` that returns true if the linkage type allows a function to be replaced by a differently optimized variant at link time. It then changes a set of IPO passes to bail out if they see such a function. Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D18634 llvm-svn: 265762
* Rename Context::discardValueNames() to shouldDiscardValueNames() (NFC)Mehdi Amini2016-04-021-1/+1
| | | | | | | Suggested by Sean Silva. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 265211
* Add a flag to the LLVMContext to disable name for Value other than GlobalValueMehdi Amini2016-03-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is intended to be a performance flag, on the same level as clang cc1 option "--disable-free". LLVM will never initialize it by default, it will be up to the client creating the LLVMContext to request this behavior. Clang will do it by default in Release build (just like --disable-free). "opt" and "llc" can opt-in using -disable-named-value command line option. When performing LTO on llvm-tblgen, the initial merging of IR peaks at 92MB without this patch, and 86MB after this patch,setNameImpl() drops from 6.5MB to 0.5MB. The total link time goes from ~29.5s to ~27.8s. Compared to a compile-time flag (like the IRBuilder one), it performs very close. I profiled on SROA and obtain these results: 420ms with IRBuilder that preserve name 372ms with IRBuilder that strip name 375ms with IRBuilder that preserve name, and a runtime flag to strip Reviewers: chandlerc, dexonsmith, bogner Subscribers: joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D17946 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 263086
* [IR] Optimize bitfield layout of Value for MSVCReid Kleckner2016-02-261-0/+2
| | | | | | | | | | | | | | | This should save a pointer of padding from all MSVC Value subclasses. Recall that MSVC will not pack the following bitfields together: unsigned Bits : 29; unsigned Flag1 : 1; unsigned Flag2 : 1; unsigned Flag3 : 1; Add a static_assert because LLVM developers always trip over this behavior. This regressed in June. llvm-svn: 262045
* 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
OpenPOWER on IntegriCloud