2012-06-21 11:51:26 +02:00
|
|
|
set(LLVM_LINK_COMPONENTS
|
|
|
|
|
Support
|
|
|
|
|
)
|
|
|
|
|
|
2018-05-14 21:23:31 +02:00
|
|
|
add_llvm_unittest(ADTTests
|
2018-07-20 18:39:32 +02:00
|
|
|
AnyTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
APFloatTest.cpp
|
|
|
|
|
APIntTest.cpp
|
2014-03-02 21:56:28 +01:00
|
|
|
APSIntTest.cpp
|
2014-02-05 23:22:56 +01:00
|
|
|
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
|
2012-06-21 11:51:26 +02:00
|
|
|
BitVectorTest.cpp
|
2017-04-06 19:03:04 +02:00
|
|
|
BreadthFirstIteratorTest.cpp
|
ADT: Add AllocatorList, and use it for yaml::Token
- Add AllocatorList, a non-intrusive list that owns an LLVM-style
allocator and provides a std::list-like interface (trivially built on
top of simple_ilist),
- add a typedef (and unit tests) for BumpPtrList, and
- use BumpPtrList for the list of llvm::yaml::Token (i.e., TokenQueueT).
TokenQueueT has no need for the complexity of an intrusive list. The
only reason to inherit from ilist was to customize the allocator.
TokenQueueT was the only example in-tree of using ilist<> in a truly
non-intrusive way.
Moreover, this removes the final use of the non-intrusive
ilist_traits<>::createNode (after r280573, r281177, and r281181). I
have a WIP patch that removes this customization point (and the API that
relies on it) that I plan to commit soon.
Note: AllocatorList owns the allocator, which limits the viable API
(e.g., splicing must be on the same list). For now I've left out
any problematic API. It wouldn't be hard to split AllocatorList into
two layers: an Impl class that calls DerivedT::getAlloc (via CRTP), and
derived classes that handle Allocator ownership/reference/etc semantics;
and then implement splice with appropriate assertions; but TBH we should
probably just customize the std::list allocators at that point.
llvm-svn: 281182
2016-09-12 00:40:40 +02:00
|
|
|
BumpPtrListTest.cpp
|
2020-02-18 14:41:55 +01:00
|
|
|
CoalescingBitVectorTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
DAGDeltaAlgorithmTest.cpp
|
|
|
|
|
DeltaAlgorithmTest.cpp
|
|
|
|
|
DenseMapTest.cpp
|
|
|
|
|
DenseSetTest.cpp
|
2016-08-22 23:59:26 +02:00
|
|
|
DepthFirstIteratorTest.cpp
|
[DDG] DirectedGraph as a base class for various dependence graphs such
as DDG and PDG.
Summary:
This is an implementation of a directed graph base class with explicit
representation of both nodes and edges. This implementation makes the
edges explicit because we expect to assign various attributes (such as
dependence type, distribution interference weight, etc) to the edges in
the derived classes such as DDG and DIG. The DirectedGraph consists of a
list of DGNode's. Each node consists of a (possibly empty) list of
outgoing edges to other nodes in the graph. A DGEdge contains a
reference to a single target node. Note that nodes do not know about
their incoming edges so the DirectedGraph class provides a function to
find all incoming edges to a given node.
This is the first patch in a series of patches that we are planning to
contribute upstream in order to implement Data Dependence Graph and
Program Dependence Graph.
More information about the proposed design can be found here:
https://ibm.ent.box.com/v/directed-graph-and-ddg
Authored By: bmahjour
Reviewer: Meinersbur, myhsum hfinkel, fhahn, jdoerfert, kbarton
Reviewed By: Meinersbur
Subscribers: mgorny, wuzish, jsji, lebedev.ri, dexonsmith, kristina,
llvm-commits, Whitney, etiotto
Tag: LLVM
Differential Revision: https://reviews.llvm.org/D64088
llvm-svn: 367043
2019-07-25 20:23:22 +02:00
|
|
|
DirectedGraphTest.cpp
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
EnumeratedArrayTest.cpp
|
2017-11-27 12:20:58 +01:00
|
|
|
EquivalenceClassesTest.cpp
|
[ADT] Add a fallible_iterator wrapper.
A fallible iterator is one whose increment or decrement operations may fail.
This would usually be supported by replacing the ++ and -- operators with
methods that return error:
class MyFallibleIterator {
public:
// ...
Error inc();
Errro dec();
// ...
};
The downside of this style is that it no longer conforms to the C++ iterator
concept, and can not make use of standard algorithms and features such as
range-based for loops.
The fallible_iterator wrapper takes an iterator written in the style above
and adapts it to (mostly) conform with the C++ iterator concept. It does this
by providing standard ++ and -- operator implementations, returning any errors
generated via a side channel (an Error reference passed into the wrapper at
construction time), and immediately jumping the iterator to a known 'end'
value upon error. It also marks the Error as checked any time an iterator is
compared with a known end value and found to be inequal, allowing early exit
from loops without redundant error checking*.
Usage looks like:
MyFallibleIterator I = ..., E = ...;
Error Err = Error::success();
for (auto &Elem : make_fallible_range(I, E, Err)) {
// Loop body is only entered when safe.
// Early exits from loop body permitted without checking Err.
if (SomeCondition)
return;
}
if (Err)
// Handle error.
* Since failure causes a fallible iterator to jump to end, testing that a
fallible iterator is not an end value implicitly verifies that the error is a
success value, and so is equivalent to an error check.
Reviewers: dblaikie, rupprecht
Subscribers: mgorny, dexonsmith, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57618
llvm-svn: 353237
2019-02-06 00:17:11 +01:00
|
|
|
FallibleIteratorTest.cpp
|
2019-10-30 00:16:05 +01:00
|
|
|
FloatingPointMode.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
FoldingSet.cpp
|
2018-07-03 01:57:29 +02:00
|
|
|
FunctionExtrasTest.cpp
|
2014-11-12 03:06:08 +01:00
|
|
|
FunctionRefTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
HashingTest.cpp
|
2016-08-23 00:21:07 +02:00
|
|
|
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
|
2016-08-23 00:21:07 +02:00
|
|
|
IListNodeBaseTest.cpp
|
2016-09-11 18:20:53 +02:00
|
|
|
IListNodeTest.cpp
|
2016-08-23 00:21:07 +02:00
|
|
|
IListSentinelTest.cpp
|
2016-08-30 02:18:43 +02:00
|
|
|
IListTest.cpp
|
2018-08-13 19:32:48 +02:00
|
|
|
ImmutableListTest.cpp
|
2012-10-14 18:06:09 +02:00
|
|
|
ImmutableMapTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
ImmutableSetTest.cpp
|
|
|
|
|
IntEqClassesTest.cpp
|
|
|
|
|
IntervalMapTest.cpp
|
|
|
|
|
IntrusiveRefCntPtrTest.cpp
|
2016-08-20 16:58:31 +02:00
|
|
|
IteratorTest.cpp
|
2017-11-10 18:41:28 +01:00
|
|
|
MappedIteratorTest.cpp
|
2013-01-25 23:29:23 +01:00
|
|
|
MapVectorTest.cpp
|
2013-02-20 01:26:04 +01:00
|
|
|
OptionalTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
PackedVectorTest.cpp
|
2016-01-10 10:40:13 +01:00
|
|
|
PointerEmbeddedIntTest.cpp
|
2014-03-07 20:19:56 +01:00
|
|
|
PointerIntPairTest.cpp
|
2016-01-10 09:48:23 +01:00
|
|
|
PointerSumTypeTest.cpp
|
2013-08-21 23:30:23 +02:00
|
|
|
PointerUnionTest.cpp
|
2014-11-20 20:33:33 +01:00
|
|
|
PostOrderIteratorTest.cpp
|
2016-06-30 04:32:20 +02:00
|
|
|
PriorityWorklistTest.cpp
|
2015-07-30 00:19:09 +02:00
|
|
|
RangeAdapterTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
SCCIteratorTest.cpp
|
2016-08-19 04:07:51 +02:00
|
|
|
STLExtrasTest.cpp
|
2016-08-10 19:52:09 +02:00
|
|
|
ScopeExitTest.cpp
|
2016-05-13 05:57:50 +02:00
|
|
|
SequenceTest.cpp
|
2016-03-25 20:28:08 +01:00
|
|
|
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
|
2012-06-21 11:51:26 +02:00
|
|
|
SmallPtrSetTest.cpp
|
2018-06-08 23:14:49 +02:00
|
|
|
SmallSetTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
SmallStringTest.cpp
|
|
|
|
|
SmallVectorTest.cpp
|
|
|
|
|
SparseBitVectorTest.cpp
|
2013-01-21 19:18:53 +01:00
|
|
|
SparseMultiSetTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
SparseSetTest.cpp
|
2018-03-05 20:38:16 +01:00
|
|
|
StatisticTest.cpp
|
2016-09-27 18:37:30 +02:00
|
|
|
StringExtrasTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
StringMapTest.cpp
|
|
|
|
|
StringRefTest.cpp
|
[ADT] Enable set_difference() to be used on StringSet
Summary: Re-land r362766 after it was reverted in r362823.
Reviewers: jhenderson, dsanders, aaron.ballman, MatzeB, lhames, dblaikie
Reviewed By: dblaikie
Subscribers: smeenai, mgrang, mgorny, dexonsmith, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62369
llvm-svn: 362835
2019-06-07 22:23:03 +02:00
|
|
|
StringSetTest.cpp
|
2016-10-03 21:56:50 +02:00
|
|
|
StringSwitchTest.cpp
|
Bring TinyPtrVector under test. Somehow we never picked up unit tests
for this class. These tests exercise most of the basic properties, but
the API for TinyPtrVector is very strange currently. My plan is to start
fleshing out the API to match that of SmallVector, but I wanted a test
for what is there first.
Sadly, it doesn't look reasonable to just re-use the SmallVector tests,
as this container can only ever store pointers, and much of the
SmallVector testing is to get construction and destruction right.
Just to get this basic test working, I had to add value_type to the
interface.
While here I found a subtle bug in the combination of 'erase', 'begin',
and 'end'. Both 'begin' and 'end' wanted to use a null pointer to
indicate the "end" iterator of an empty vector, regardless of whether
there is actually a vector allocated or the pointer union is null.
Everything else was fine with this except for erase. If you erase the
last element of a vector after it has held more than one element, we
return the end iterator of the underlying SmallVector which need not be
a null pointer. Instead, simply use the pointer, and poniter + size()
begin/end definitions in the tiny case, and delegate to the inner vector
whenever it is present.
llvm-svn: 161024
2012-07-31 04:48:31 +02:00
|
|
|
TinyPtrVectorTest.cpp
|
2012-06-21 11:51:26 +02:00
|
|
|
TripleTest.cpp
|
|
|
|
|
TwineTest.cpp
|
2020-04-14 23:53:50 +02:00
|
|
|
TypeSwitchTest.cpp
|
2020-04-14 23:52:52 +02:00
|
|
|
TypeTraitsTest.cpp
|
2020-03-31 15:46:01 +02:00
|
|
|
WaymarkingTest.cpp
|
2012-08-30 18:22:32 +02:00
|
|
|
)
|
2015-06-16 02:44:12 +02:00
|
|
|
|
[ADT] Add a fallible_iterator wrapper.
A fallible iterator is one whose increment or decrement operations may fail.
This would usually be supported by replacing the ++ and -- operators with
methods that return error:
class MyFallibleIterator {
public:
// ...
Error inc();
Errro dec();
// ...
};
The downside of this style is that it no longer conforms to the C++ iterator
concept, and can not make use of standard algorithms and features such as
range-based for loops.
The fallible_iterator wrapper takes an iterator written in the style above
and adapts it to (mostly) conform with the C++ iterator concept. It does this
by providing standard ++ and -- operator implementations, returning any errors
generated via a side channel (an Error reference passed into the wrapper at
construction time), and immediately jumping the iterator to a known 'end'
value upon error. It also marks the Error as checked any time an iterator is
compared with a known end value and found to be inequal, allowing early exit
from loops without redundant error checking*.
Usage looks like:
MyFallibleIterator I = ..., E = ...;
Error Err = Error::success();
for (auto &Elem : make_fallible_range(I, E, Err)) {
// Loop body is only entered when safe.
// Early exits from loop body permitted without checking Err.
if (SomeCondition)
return;
}
if (Err)
// Handle error.
* Since failure causes a fallible iterator to jump to end, testing that a
fallible iterator is not an end value implicitly verifies that the error is a
success value, and so is equivalent to an error check.
Reviewers: dblaikie, rupprecht
Subscribers: mgorny, dexonsmith, kristina, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57618
llvm-svn: 353237
2019-02-06 00:17:11 +01:00
|
|
|
target_link_libraries(ADTTests PRIVATE LLVMTestingSupport)
|
|
|
|
|
|
2015-06-16 02:44:12 +02:00
|
|
|
add_dependencies(ADTTests intrinsics_gen)
|
