1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-22 20:43:44 +02:00
Commit Graph

4 Commits

Author SHA1 Message Date
Joerg Sonnenberger
100750a643 Turn LLVM_ENABLE_ABI_BREAKING_CHECKS into a 0/1 definition like
LLVM_ENABLE_THREADS. Include llvm-config.h explicitly in headers to make
sure that the definition is available.

llvm-svn: 282907
2016-09-30 19:52:27 +00:00
Duncan P. N. Exon Smith
2a55cf5af8 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 16:20:53 +00:00
Duncan P. N. Exon Smith
997810cad7 ADT: Move ilist_node_access to ilist_detail::NodeAccess...
... and make a few ilist-internal API changes, in preparation for
changing how ilist_node is templated.  The only effect for ilist users
should be changing the friend target from llvm::ilist_node_access to
llvm::ilist_detail::NodeAccess (which is only necessary when they
inherit privately from ilist_node).
- Split out SpecificNodeAccess, which has overloads of getNodePtr and
  getValuePtr that are untemplated.
- Use more typedefs to prevent more changes later.
- Force inheritance to use *NodeAccess (to emphasize that ilist *users*
  shouldn't be doing this).

There should be no functionality change here.

llvm-svn: 281142
2016-09-10 16:55:06 +00:00
Duncan P. N. Exon Smith
38ac81f154 ADT: Separate some list manipulation API into ilist_base, NFC
Separate algorithms in iplist<T> that don't depend on T into ilist_base,
and unit test them.

While I was adding unit tests for these algorithms anyway, I also added
unit tests for ilist_node_base and ilist_sentinel<T>.

To make the algorithms and unit tests easier to write, I also did the
following minor changes as a drive-by:
- encapsulate Prev/Next in ilist_node_base to so that algorithms are
  easier to read, and
- update ilist_node_access API to take nodes by reference.

There should be no real functionality change here.

llvm-svn: 279484
2016-08-22 22:21:07 +00:00