summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/IR/ValueHandleTest.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Add a new WeakVH value handle; NFCSanjoy Das2017-05-011-0/+18
| | | | | | This relands r301425. llvm-svn: 301813
* Rename WeakVH to WeakTrackingVH; NFCSanjoy Das2017-05-011-20/+20
| | | | | | This relands r301424. llvm-svn: 301812
* Emulate TrackingVH using WeakVHSanjoy Das2017-05-011-0/+26
| | | | | | | | | | | | | | | | Summary: This frees up one slot in the HandleBaseKind enum, which I will use later to add a new kind of value handle. The size of the HandleBaseKind enum is important because we store a HandleBaseKind in the low two bits of a (in the worst case) 4 byte aligned pointer. Reviewers: davide, chandlerc Subscribers: mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D32634 llvm-svn: 301809
* Reverts commit r301424, r301425 and r301426Sanjoy Das2017-04-261-36/+18
| | | | | | | | | | | | 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-0/+18
| | | | | | | | | | | | | | 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-20/+20
| | | | | | | | | | | | | | | | 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
* [PM] Introduce a PoisoningVH as a (more expensive) alternative toChandler Carruth2017-01-241-0/+93
| | | | | | | | | | | | | | | | | | | | | | | | AssertingVH that delays any reported error until the handle is *used*. This allows data structures to contain handles which become dangling provided the data structure is cleaned up afterward rather than used for anything interesting. The implementation is moderately horrible in part because it works to leave AssertingVH in place, undisturbed. If at some point there is consensus that this is simply how AssertingVH should be used, it can be substantially simplified. This remains a boring pointer in a non-asserts build as you would expect. The only place we pay cost is in asserts builds. I plan to use this as a basis for replacing the asserting VHs that currently dangle in the new PM until invalidation occurs in both LVI and SCEV. Differential Revision: https://reviews.llvm.org/D29061 llvm-svn: 292925
* Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini2016-04-141-21/+23
| | | | | | | | | | | At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
* -Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are ↵David Blaikie2015-08-031-6/+6
| | | | | | | | | | | | | | | | | | | | | | 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
* Replace std::auto_ptr with std::unique_ptrDavid Blaikie2015-04-221-2/+2
| | | | | | | | | std::auto_ptr is deprecated in GCC 5.0, and we are already using std::unique_ptr all over the place. Patch by Xan López. llvm-svn: 235479
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-9/+15
| | | | | | | | | | | | | | 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
* [C++11] Use 'nullptr'.Craig Topper2014-06-081-16/+16
| | | | llvm-svn: 210442
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-2/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* [Modules] Move ValueHandle into the IR library where Value itself lives.Chandler Carruth2014-03-041-0/+408
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
OpenPOWER on IntegriCloud