Again, I'd like to emphasize to everyone that this sort of markup change
is *not* what you should be concerned about when writing docs. Focus on
*content*.
I applaud Chandler for focusing on the fantastic content of this new
section!
llvm-svn: 227305
polymorphism, and virtual dispatch.
This is essentially trying to explain the emerging design techniques
being used in LLVM these days somewhere more accessible than the
comments on a particular piece of infrastructure. It covers the
"concepts-based polymorphism" that caused some confusion during initial
reviews of the new pass manager as well as the tagged-dispatch mechanism
used pervasively in LLVM and Clang.
Perhaps most notably, I've tried to provide some criteria to help
developers choose between these options when designing new pieces of
infrastructure.
Differential Revision: http://reviews.llvm.org/D7191
llvm-svn: 227292
Summary: This patch introduces two new iterator ranges and updates existing code to use it. No functional change intended.
Test Plan: All tests (make check-all) still pass.
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D4481
llvm-svn: 213474
Add a `MapVector::remove_if()` that erases items in bulk in linear time,
as opposed to quadratic time for repeated calls to `MapVector::erase()`.
llvm-svn: 213090
Actually update the changed indexes in the map portion of `MapVector`
when erasing from the middle. Add a unit test that checks for this.
Note that `MapVector::erase()` is a linear time operation (it was and
still is). I'll commit a new method in a moment called
`MapVector::remove_if()` that deletes multiple entries in linear time,
which should be slightly less painful.
llvm-svn: 213084
After a number of previous small iterations, the functions
llvm_start_multithreaded() and llvm_stop_multithreaded() have
been reduced essentially to no-ops. This change removes them
entirely.
Reviewed by: rnk, dblaikie
Differential Revision: http://reviews.llvm.org/D4216
llvm-svn: 211287
This patch removes the LLVM global lock, and updates all existing
users of the global lock to use their own mutex. None of the
existing users of the global lock were protecting code that was
mutually exclusive with any of the other users of the global
lock, so its purpose was not being met.
Reviewed by: rnk
Differential Revision: http://reviews.llvm.org/D4142
llvm-svn: 211277
Replace the crufty build-time configure checks for program paths with
equivalent runtime logic.
This lets users install graphing tools as needed without having to reconfigure
and rebuild LLVM, while eliminating a long chain of inappropriate compile
dependencies that included GUI programs and the windowing system.
Additional features:
* Support the OS X 'open' command to view graphs generated by any of the
Graphviz utilities. This is an alternative to the Graphviz OS X UI which is
no longer available on Mountain Lion.
* Produce informative log output upon failure to indicate which programs can
be installed to view graphs.
Ping me if this doesn't work for your particular environment.
llvm-svn: 210001
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
llvm-svn: 202824
std::lower_bound is the canonical "binary search" in the STL
(std::binary_search generally is not what you want). The name actually
makes a lot of sense (and also has a beautiful symmetry with the
std::upper_bound algorithm). The name is nonetheless non-obvious.
Also, remove mention of "radix search". It's not even clear how that
would work in the context of a sorted vector. AFAIK "radix search" only
makes sense when you have a trie-like data structure.
llvm-svn: 178376
The new wording cannot be construed as suggesting the use of
SmallVectorImpl<T> as e.g. a class member (just because the class
happens to be in an interface).
llvm-svn: 177778
Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.
This fixes PR14891 as a special case.
llvm-svn: 172162
Sean Silva