1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
llvm-mirror/unittests/ADT/CMakeLists.txt

73 lines
1.4 KiB
CMake
Raw Normal View History

set(LLVM_LINK_COMPONENTS
Support
)
set(ADTSources
APFloatTest.cpp
APIntTest.cpp
APSIntTest.cpp
ArrayRefTest.cpp
[ADT] Add LLVM_MARK_AS_BITMASK_ENUM, used to enable bitwise operations on enums without static_cast. Summary: Normally when you do a bitwise operation on an enum value, you get back an instance of the underlying type (e.g. int). But using this macro, bitwise ops on your enum will return you back instances of the enum. This is particularly useful for enums which represent a combination of flags. Suppose you have a function which takes an int and a set of flags. One way to do this would be to take two numeric params: enum SomeFlags { F1 = 1, F2 = 2, F3 = 4, ... }; void Fn(int Num, int Flags); void foo() { Fn(42, F2 | F3); } But now if you get the order of arguments wrong, you won't get an error. You might try to fix this by changing the signature of Fn so it accepts a SomeFlags arg: enum SomeFlags { F1 = 1, F2 = 2, F3 = 4, ... }; void Fn(int Num, SomeFlags Flags); void foo() { Fn(42, static_cast<SomeFlags>(F2 | F3)); } But now we need a static cast after doing "F2 | F3" because the result of that computation is the enum's underlying type. This patch adds a mechanism which gives us the safety of the second approach with the brevity of the first. enum SomeFlags { F1 = 1, F2 = 2, F3 = 4, ..., F_MAX = 128, LLVM_MARK_AS_BITMASK_ENUM(F_MAX) }; void Fn(int Num, SomeFlags Flags); void foo() { Fn(42, F2 | F3); // No static_cast. } The LLVM_MARK_AS_BITMASK_ENUM macro enables overloads for bitwise operators on SomeFlags. Critically, these operators return the enum type, not its underlying type, so you don't need any static_casts. An advantage of this solution over the previously-proposed BitMask class [0, 1] is that we don't need any wrapper classes -- we can operate directly on the enum itself. The approach here is somewhat similar to OpenOffice's typed_flags_set [2]. But we skirt the need for a wrapper class (and a good deal of complexity) by judicious use of enable_if. We SFINAE on the presence of a particular enumerator (added by the LLVM_MARK_AS_BITMASK_ENUM macro) instead of using a traits class so that it's impossible to use the enum before the overloads are present. The solution here also seamlessly works across multiple namespaces. [0] http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150622/283369.html [1] http://lists.llvm.org/pipermail/llvm-commits/attachments/20150623/073434b6/attachment.obj [2] https://cgit.freedesktop.org/libreoffice/core/tree/include/o3tl/typed_flags_set.hxx Reviewers: chandlerc, rsmith Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D22279 llvm-svn: 275292
2016-07-13 20:23:16 +02:00
BitmaskEnumTest.cpp
BitVectorTest.cpp
BreadthFirstIteratorTest.cpp
BumpPtrListTest.cpp
DAGDeltaAlgorithmTest.cpp
DeltaAlgorithmTest.cpp
DenseMapTest.cpp
DenseSetTest.cpp
DepthFirstIteratorTest.cpp
FoldingSet.cpp
FunctionRefTest.cpp
HashingTest.cpp
IListBaseTest.cpp
ADT: Give ilist<T>::reverse_iterator a handle to the current node Reverse iterators to doubly-linked lists can be simpler (and cheaper) than std::reverse_iterator. Make it so. In particular, change ilist<T>::reverse_iterator so that it is *never* invalidated unless the node it references is deleted. This matches the guarantees of ilist<T>::iterator. (Note: MachineBasicBlock::iterator is *not* an ilist iterator, but a MachineInstrBundleIterator<MachineInstr>. This commit does not change MachineBasicBlock::reverse_iterator, but it does update MachineBasicBlock::reverse_instr_iterator. See note at end of commit message for details on bundle iterators.) Given the list (with the Sentinel showing twice for simplicity): [Sentinel] <-> A <-> B <-> [Sentinel] the following is now true: 1. begin() represents A. 2. begin() holds the pointer for A. 3. end() represents [Sentinel]. 4. end() holds the poitner for [Sentinel]. 5. rbegin() represents B. 6. rbegin() holds the pointer for B. 7. rend() represents [Sentinel]. 8. rend() holds the pointer for [Sentinel]. The changes are #6 and #8. Here are some properties from the old scheme (which used std::reverse_iterator): - rbegin() held the pointer for [Sentinel] and rend() held the pointer for A; - operator*() cost two dereferences instead of one; - converting from a valid iterator to its valid reverse_iterator involved a confusing increment; and - "RI++->erase()" left RI invalid. The unintuitive replacement was "RI->erase(), RE = end()". With vector-like data structures these properties are hard to avoid (since past-the-beginning is not a valid pointer), and don't impose a real cost (since there's still only one dereference, and all iterators are invalidated on erase). But with lists, this was a poor design. Specifically, the following code (which obviously works with normal iterators) now works with ilist::reverse_iterator as well: for (auto RI = L.rbegin(), RE = L.rend(); RI != RE;) fooThatMightRemoveArgFromList(*RI++); Converting between iterator and reverse_iterator for the same node uses the getReverse() function. reverse_iterator iterator::getReverse(); iterator reverse_iterator::getReverse(); Why doesn't iterator <=> reverse_iterator conversion use constructors? In order to catch and update old code, reverse_iterator does not even have an explicit conversion from iterator. It wouldn't be safe because there would be no reasonable way to catch all the bugs from the changed semantic (see the changes at call sites that are part of this patch). Old code used this API: std::reverse_iterator::reverse_iterator(iterator); iterator std::reverse_iterator::base(); Here's how to update from old code to new (that incorporates the semantic change), assuming I is an ilist<>::iterator and RI is an ilist<>::reverse_iterator: [Old] ==> [New] reverse_iterator(I) (--I).getReverse() reverse_iterator(I) ++I.getReverse() --reverse_iterator(I) I.getReverse() reverse_iterator(++I) I.getReverse() RI.base() (--RI).getReverse() RI.base() ++RI.getReverse() --RI.base() RI.getReverse() (++RI).base() RI.getReverse() delete &*RI, RE = end() delete &*RI++ RI->erase(), RE = end() RI++->erase() ======================================= Note: bundle iterators are out of scope ======================================= MachineBasicBlock::iterator, also known as MachineInstrBundleIterator<MachineInstr>, is a wrapper to represent MachineInstr bundles. The idea is that each operator++ takes you to the beginning of the next bundle. Implementing a sane reverse iterator for this is harder than ilist. Here are the options: - Use std::reverse_iterator<MBB::i>. Store a handle to the beginning of the next bundle. A call to operator*() runs a loop (usually operator--() will be called 1 time, for unbundled instructions). Increment/decrement just works. This is the status quo. - Store a handle to the final node in the bundle. A call to operator*() still runs a loop, but it iterates one time fewer (usually operator--() will be called 0 times, for unbundled instructions). Increment/decrement just works. - Make the ilist_sentinel<MachineInstr> *always* store that it's the sentinel (instead of just in asserts mode). Then the bundle iterator can sniff the sentinel bit in operator++(). I initially tried implementing the end() option as part of this commit, but updating iterator/reverse_iterator conversion call sites was error-prone. I have a WIP series of patches that implements the final option. llvm-svn: 280032
2016-08-30 02:13:12 +02:00
IListIteratorTest.cpp
IListNodeBaseTest.cpp
ADT: Add sentinel tracking and custom tags to ilists This adds two declarative configuration options for intrusive lists (available for simple_ilist, iplist, and ilist). Both of these options affect ilist_node interoperability and need to be passed both to the node and the list. Instead of adding a new traits class, they're specified as optional template parameters (in any order). The two options: 1. Pass ilist_sentinel_tracking<true> or ilist_sentinel_tracking<false> to control whether there's a bit on ilist_node "prev" pointer indicating whether it's the sentinel. The default behaviour is to use a bit if and only if LLVM_ENABLE_ABI_BREAKING_CHECKS. 2. Pass ilist_tag<TagA> and ilist_tag<TagB> to allow insertion of a single node into two different lists (simultaneously). I have an immediate use-case for (1) ilist_sentinel_tracking: fixing the validation semantics of MachineBasicBlock::reverse_iterator to match ilist::reverse_iterator (ala r280032: see the comments at the end of the commit message there). I'm adding (2) ilist_tag in the same commit to validate that the options framework supports expansion. Justin Bogner mentioned this might enable a possible cleanup in SelectionDAG, but I'll leave this to others to explore. In the meantime, the unit tests and the comments for simple_ilist and ilist_node have usage examples. Note that there's a layer of indirection to support optional, out-of-order, template paramaters. Internal classes are templated on an instantiation of the non-variadic ilist_detail::node_options. User-facing classes use ilist_detail::compute_node_options to compute the correct instantiation of ilist_detail::node_options. The comments for ilist_detail::is_valid_option describe how to add new options (e.g., ilist_packed_int<int NumBits>). llvm-svn: 281167
2016-09-11 18:20:53 +02:00
IListNodeTest.cpp
IListSentinelTest.cpp
IListTest.cpp
2012-10-14 18:06:09 +02:00
ImmutableMapTest.cpp
ImmutableSetTest.cpp
IntEqClassesTest.cpp
IntervalMapTest.cpp
IntrusiveRefCntPtrTest.cpp
IteratorTest.cpp
MakeUniqueTest.cpp
MappedIteratorTest.cpp
MapVectorTest.cpp
OptionalTest.cpp
PackedVectorTest.cpp
PointerEmbeddedIntTest.cpp
PointerIntPairTest.cpp
PointerSumTypeTest.cpp
PointerUnionTest.cpp
PostOrderIteratorTest.cpp
PriorityWorklistTest.cpp
RangeAdapterTest.cpp
SCCIteratorTest.cpp
STLExtrasTest.cpp
ScopeExitTest.cpp
SequenceTest.cpp
SetVectorTest.cpp
ADT: Split out simple_ilist, a simple intrusive list Split out a new, low-level intrusive list type with clear semantics. Unlike iplist (and ilist), all operations on simple_ilist are intrusive, and simple_ilist never takes ownership of its nodes. This enables an intuitive API that has the right defaults for intrusive lists. - insert() takes references (not pointers!) to nodes (in iplist/ilist, passing a reference will cause the node to be copied). - erase() takes only iterators (like std::list), and does not destroy the nodes. - remove() takes only references and has the same behaviour as erase(). - clear() does not destroy the nodes. - The destructor does not destroy the nodes. - New API {erase,remove,clear}AndDispose() take an extra Disposer functor for callsites that want to call some disposal routine (e.g., std::default_delete). This list is not currently configurable, and has no callbacks. The initial motivation was to fix iplist<>::sort to work correctly (even with callbacks in ilist_traits<>). iplist<> uses simple_ilist<>::sort directly. The new test in unittests/IR/ModuleTest.cpp crashes without this commit. Fixing sort() via a low-level layer provided a good opportunity to: - Unit test the low-level functionality thoroughly. - Modernize the API, largely inspired by other intrusive list implementations. Here's a sketch of a longer-term plan: - Create BumpPtrList<>, a non-intrusive list implemented using simple_ilist<>, and use it for the Token list in lib/Support/YAMLParser.cpp. This will factor out the only real use of createNode(). - Evolve the iplist<> and ilist<> APIs in the direction of simple_ilist<>, making allocation/deallocation explicit at call sites (similar to simple_ilist<>::eraseAndDispose()). - Factor out remaining calls to createNode() and deleteNode() and remove the customization from ilist_traits<>. - Transition uses of iplist<>/ilist<> that don't need callbacks over to simple_ilist<>. llvm-svn: 280107
2016-08-30 18:23:55 +02:00
SimpleIListTest.cpp
SmallPtrSetTest.cpp
SmallStringTest.cpp
SmallVectorTest.cpp
SparseBitVectorTest.cpp
SparseMultiSetTest.cpp
SparseSetTest.cpp
StringExtrasTest.cpp
StringMapTest.cpp
StringRefTest.cpp
StringSwitchTest.cpp
TinyPtrVectorTest.cpp
TripleTest.cpp
TwineTest.cpp
VariadicFunctionTest.cpp
)
add_llvm_unittest(ADTTests
${ADTSources}
)
add_dependencies(ADTTests intrinsics_gen)