This patch adds support of NativeClient (*-*-nacl) OS support to LLVM.
It's already supported in autoconf/config.sub.
The motivation for this change is to start upstreaming PNaCl work. The
whole set of patches include llvm backends (i686, x86_64, ARM),
llvm-gcc (probably, would not be upstreamed because it's deprecated)
and clang (the work has been just started, the amount of changes is
going to be low and the most of the work is expected to be done close
to the mainline).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138005 91177308-0d34-0410-b5e6-96231b3b80d8
when checking isNull(), we'd pick off the sentinel bit for the outer
PointerUnion, but would not recursively convert the inner pointerunion to bool,
so if *its* sentinel bit is set, isNull() would incorrectly return false.
No testcase, because someone hit this when they were trying to refactor code
to use PointerUnion3, but they since found a better solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137428 91177308-0d34-0410-b5e6-96231b3b80d8
Create a std::string wrapper for use as a DenseMap key. DenseMap is
not safe in generate with strings, so this wrapper indicates that only
strings guaranteed not to have certain values should be used in the
DenseMap.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136481 91177308-0d34-0410-b5e6-96231b3b80d8
of the empty key for U. This shouldn't really matter because the tombstone key
for the pair was still distinct from every other key, but it is odd. Patch by
Michael Ilseman!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136336 91177308-0d34-0410-b5e6-96231b3b80d8
errors like the one corrected by r135261. Migrate all LLVM callers of the old
constructor to the new one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135431 91177308-0d34-0410-b5e6-96231b3b80d8
They mostly mirror the ArrayRef constructors, with two exceptions:
* There's no function mirroring the default constructor because it wouldn't have any parameters to deduce the right ArrayRef<T> from.
* There's an explicit SmallVector<T> overload in addition to the SmallVectorImpl<T> overload. Without it, the single-element overload would try to create an ArrayRef<Smallvector<T> > because it's a better match according to the overloading rules. (And both overloads are used in the current tree, so neither is redundant)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135389 91177308-0d34-0410-b5e6-96231b3b80d8
ExtractValueInst APIs to use ArrayRef: a new constructor taking a
(begin, end) range, and operators == and != for element-wise comparison.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135039 91177308-0d34-0410-b5e6-96231b3b80d8
vec.insert(vec.begin(), vec[3]);
The issue was that vec[3] returns a reference into the vector, which is invalidated when insert() memmove's the elements down to make space. The method needs to specifically detect and handle this case to correctly match std::vector's semantics.
Thanks to Howard Hinnant for clarifying the correct behavior, and explaining how std::vector solves this problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134554 91177308-0d34-0410-b5e6-96231b3b80d8
representing a constant reference to ValType. Normally this is just
"const ValType &", but when ValType is a std::vector we want to use
ArrayRef as the reference type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133611 91177308-0d34-0410-b5e6-96231b3b80d8
toString() now takes an optional bool argument that,
depending on the radix, adds the appropriate prefix
to the integer's string representation that makes it into a
meaningful C literal, e.g.:
hexademical: '-f' becomes '-0xf'
octal: '77' becomes '077'
binary: '110' becomes '0b110'
Patch by nobled@dreamwidth.org!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133032 91177308-0d34-0410-b5e6-96231b3b80d8
value. Both signed and unsigned types can be used, e.g
PackedVector<signed, 2> vec;
will create a vector accepting values -2, -1, 0, 1. Any other value will hit an assertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132325 91177308-0d34-0410-b5e6-96231b3b80d8
This is important for the correct lowering of unwind instructions
(which doesn't matter at all) and llvm.eh.resume calls (which does).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132291 91177308-0d34-0410-b5e6-96231b3b80d8
-strlen should not be called with NULL. Also guarantee that StringRef's Length is 0 if Data is NULL.
-memcmp should not be called with NULL (even if size is 0)
Patch by Matthieu Monrocq!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131747 91177308-0d34-0410-b5e6-96231b3b80d8
used by Clang. To help Clang integration, the PTX target has been split
into two targets: ptx32 and ptx64, depending on the desired pointer size.
- Add GCCBuiltin class to all intrinsics
- Split PTX target into ptx32 and ptx64
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129851 91177308-0d34-0410-b5e6-96231b3b80d8
When the greedy register allocator is splitting multiple global live ranges, it
tends to look at the same interference data many times. The InterferenceCache
class caches queries for unaltered LiveIntervalUnions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128764 91177308-0d34-0410-b5e6-96231b3b80d8
StringMap was not properly updating NumTombstones after a clear or rehash.
This was not fatal until now because the table was growing faster than
NumTombstones could, but with the previous change of preventing infinite
growth of the table the invariant (NumItems + NumTombstones <= NumBuckets)
stopped being observed, causing infinite loops in certain situations.
Patch by José Fonseca!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128567 91177308-0d34-0410-b5e6-96231b3b80d8
When the hash function uses object pointers all free entries eventually
become tombstones as they are used at least once, regardless of the size.
DenseMap cannot function with zero empty keys, so it double size to get
get ridof the tombstones.
However DenseMap never shrinks automatically unless it is cleared, so
the net result is that certain tables grow infinitely.
The solution is to make a fresh copy of the table without tombstones
instead of doubling size, by simply calling grow with the current size.
Patch by José Fonseca!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128564 91177308-0d34-0410-b5e6-96231b3b80d8
The idea is, that if an ieee 754 float is divided by a power of two, we can
turn the division into a cheaper multiplication. This function sees if we can
get an exact multiplicative inverse for a divisor and returns it if possible.
This is the hard part of PR9587.
I tested many inputs against llvm-gcc's frotend implementation of this
optimization and didn't find any difference. However, floating point is the
land of weird edge cases, so any review would be appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128545 91177308-0d34-0410-b5e6-96231b3b80d8
This makes lookup slightly more expensive but it's worth it, unused
DenseMaps are common in LLVM code apparently.
1% speedup on clang -O3 bzip2.c
4% speedup on clang -O3 oggenc.c (Release build of clang on i386/linux)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127088 91177308-0d34-0410-b5e6-96231b3b80d8
template <class T1, class T2> pair<T1,T2> make_pair(const T1&, const T2&);
to
template <class T1, class T2> pair<V1, V2> make_pair(T1&&, T2&&);
so explicitly specifying the template arguments to make_pair<> is going to break
when C++0x rolls through. Replace them with equivalent std::pair<>. Patch by
James Dennett!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126256 91177308-0d34-0410-b5e6-96231b3b80d8
No one uses *-mingw64. mingw-w64 is represented as {i686|x86_64}-w64-mingw32. In llvm side, i686 and x64 can be treated as similar way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125747 91177308-0d34-0410-b5e6-96231b3b80d8
use in many places where we pass a pointer and size to abstract APIs
that can take C arrays, std::vector, SmallVector, etc. It is to arrays
what StringRef is to strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125486 91177308-0d34-0410-b5e6-96231b3b80d8
objects, since they'll end up using the implicit conversion to "bool"
and causing some very "fun" surprises.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125380 91177308-0d34-0410-b5e6-96231b3b80d8
may be useful to understand "none", this is not the place for it. Tweak
the fix to Normalize while there: the fix added in 123990 works correctly,
but I like this way better. Finally, now that Triple understands some
non-trivial environment values, teach the unittests about them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124720 91177308-0d34-0410-b5e6-96231b3b80d8
when no virtual registers have been allocated.
It was only used to resize IndexedMaps, so provide an IndexedMap::resize()
method such that
Map.grow(MRI.getLastVirtReg());
can be replaced with the simpler
Map.resize(MRI.getNumVirtRegs());
This works correctly when no virtuals are allocated, and it bypasses the to/from
index conversions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123130 91177308-0d34-0410-b5e6-96231b3b80d8
This implementation already exists as ConnectedVNInfoEqClasses in
LiveInterval.cpp, and it seems to be generally useful to have a light-weight way
of forming equivalence classes of small integers.
IntEqClasses doesn't allow enumeration of the elements in a class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122293 91177308-0d34-0410-b5e6-96231b3b80d8
moves the iterator to end(), and it is valid to call it on end().
That means it is valid to call advanceTo() with any monotonic key sequence.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122092 91177308-0d34-0410-b5e6-96231b3b80d8
This is a three-way interval list intersection between a virtual register, a
live interval union, and a loop. It will be used to identify interference-free
loops for live range splitting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122034 91177308-0d34-0410-b5e6-96231b3b80d8
IntervalMaps.
The IntervalMaps can have different template parameters, but the KeyT and Traits
types must be the same.
Tests are forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121935 91177308-0d34-0410-b5e6-96231b3b80d8
zextOrTrunc(), and APSInt methods extend(), extOrTrunc() and new method
trunc(), to be const and to return a new value instead of modifying the
object in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121120 91177308-0d34-0410-b5e6-96231b3b80d8
editing of the current interval.
These methods may cause coalescing, there are corresponding set*Unchecked
methods for editing without coalescing. The non-coalescing methods are useful
for applying monotonic transforms to all keys or values in a map without
accidentally coalescing transformed and untransformed intervals.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120829 91177308-0d34-0410-b5e6-96231b3b80d8
- Use a DenseSet instead of a FoldingSet to cache
canonicalized nodes. This reduces the overhead
of double-hashing.
- Use reference counts in ImutAVLTree to much
more aggressively recover tree nodes that are
no longer usable. We can generate many
transient nodes while using add() and remove()
on ImmutableSet/ImmutableMaps to generate a final
set/map.
For the clang static analyzer (the main client
of these data structures), this results in
a slight speedup (0.5%) when analyzing sqlite3,
but much more importantly results in a 30-60%
reduction in peak memory usage when the analyzer
is analyzing a given function in a file. On
average that's about a ** 44% reduction ** in the
memory footprint of the static analyzer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120459 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes std::copy can become a memmove call, and that is not a good idea when
copying relatively few bytes as we are doing. We also get a small win by
changing two loops into one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120265 91177308-0d34-0410-b5e6-96231b3b80d8
We always disallowed overlapping inserts with different values, and this makes
the insertion code smaller and faster.
If an overwriting insert is needed, it can be added as a separate method that
trims any existing intervals before inserting. The immediate use cases for
IntervalMap don't need this - they only use disjoint insertions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120264 91177308-0d34-0410-b5e6-96231b3b80d8
These iterators don't point anywhere, and they can't be compared to anything.
They are only good for assigning to.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120239 91177308-0d34-0410-b5e6-96231b3b80d8
Implement iterator::erase() in a simple version that erases nodes when they
become empty, but doesn't try to redistribute elements among siblings for better
packing.
Handle coalescing across leaf nodes which may require erasing entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120226 91177308-0d34-0410-b5e6-96231b3b80d8
situations where on the common path an API can return a pointer to some direct
memory, but which on an exceptional path may need to return a pointer to a
temporary struct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120201 91177308-0d34-0410-b5e6-96231b3b80d8
- Double the vector's capacity when growing to avoid unneeccesary reallocation.
- Do the reallocation with realloc(3) which can expand the memory in place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120183 91177308-0d34-0410-b5e6-96231b3b80d8
The path also holds a reference to the root node, and that allows important
iterator accessors like start() and stop() to have no conditional code. (When
the compiler is clever enough to remove it.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120165 91177308-0d34-0410-b5e6-96231b3b80d8
to use lowercase letters for the start of most
method names and to replace some method names
with more descriptive names (e.g., "getLeft()"
instead of "Left()"). No real functionality
change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120070 91177308-0d34-0410-b5e6-96231b3b80d8
This doesn't quite work yet because the calls to treeDecrement and treeIncrement
operate at the leaf level, not on pathNode(Level) as required.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120068 91177308-0d34-0410-b5e6-96231b3b80d8
It is now possible to navigate the B+-tree using NodeRef::subtree() and
NodeRef::size() without knowing the key and value template types used in the
tree.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119880 91177308-0d34-0410-b5e6-96231b3b80d8
that the noderefs are the first member in the object.
This is in preparation of detemplatization of tree navigation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119879 91177308-0d34-0410-b5e6-96231b3b80d8
Key and value objects may not be destructed instantly when they are erased from
the container, but they will be destructed eventually by the IntervalMap
destructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119873 91177308-0d34-0410-b5e6-96231b3b80d8
llvm/include/llvm/ADT/IntervalMap.h:334: error: '((llvm::IntervalMapImpl::DesiredNodeBytes / static_cast<unsigned int>(((2 * sizeof (KeyT)) + sizeof (ValT)))) >? 3u)' is not a valid template argument for type 'unsigned int' because it is a non-constant expression
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119790 91177308-0d34-0410-b5e6-96231b3b80d8
This is a sorted interval map data structure for small keys and values with
automatic coalescing and bidirectional iteration over coalesced intervals.
Except for coalescing intervals, it provides similar functionality to std::map.
It is however much more compact for small keys and values, and hopefully faster
too.
The container object itself can hold the first few intervals without any
allocations, then it switches to a cache conscious B+-tree representation. A
recycling allocator can be shared between many containers, even between
containers holding different types.
The IntervalMap is initially intended to be used with SlotIndex intervals for:
- Backing store for LiveIntervalUnion that is smaller and faster than std::set.
- Backing store for LiveInterval with less overhead than std::vector for typical
intervals and O(N log N) merging of large intervals. 99% of virtual registers
need 4 entries or less and would benefit from the small object optimization.
- Backing store for LiveDebugVariable which doesn't exist yet, but will track
debug variables during register allocation.
This is a work in progress. Missing items are:
- Performance metrics.
- erase().
- insert() shrinkage.
- clear().
- More performance metrics.
- Simplification and detemplatization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119787 91177308-0d34-0410-b5e6-96231b3b80d8
This is a sorted interval map data structure for small keys and values with
automatic coalescing and bidirectional iteration over coalesced intervals.
Except for coalescing intervals, it provides similar functionality to std::map.
It is however much more compact for small keys and values, and hopefully faster
too.
The container object itself can hold the first few intervals without any
allocations, then it switches to a cache conscious B+-tree representation. A
recycling allocator can be shared between many containers, even between
containers holding different types.
The IntervalMap is initially intended to be used with SlotIndex intervals for:
- Backing store for LiveIntervalUnion that is smaller and faster than std::set.
- Backing store for LiveInterval with less overhead than std::vector for typical
intervals and O(N log N) merging of large intervals. 99% of virtual registers
need 4 entries or less and would benefit from the small object optimization.
- Backing store for LiveDebugVariable which doesn't exist yet, but will track
debug variables during register allocation.
This is a work in progress. Missing items are:
- Performance metrics.
- erase().
- insert() shrinkage.
- clear().
- More performance metrics.
- Simplification and detemplatization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119772 91177308-0d34-0410-b5e6-96231b3b80d8
specializations provided here. This is a little annoying because its size
changes from platform to platform. If possible, I may follow up with a patch
that uses standard constants to simplify much of this, but assuming for now
that was avoided for a reason.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117880 91177308-0d34-0410-b5e6-96231b3b80d8
logic to use the new APInt methods. Among other things this
implements rdar://8501501 - llvm.smul.with.overflow.i32 should constant fold
which comes from "clang -ftrapv", originally brought to my attention from PR8221.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116457 91177308-0d34-0410-b5e6-96231b3b80d8
is partly because this attribute caused trouble in the past (the
SmallVector one had to be changed from aligned to aligned(8) due
to causing crashes on i386 for example; in theory the same might
be needed in the Allocator case...). But it's mostly because
there seems to be no point in special casing gcc here. Using the
same implementation for all compilers results in better testing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115462 91177308-0d34-0410-b5e6-96231b3b80d8
capacity and remove the workaround in SmallVector<T,0>. There are some
theoretical benefits to a N->2N+1 growth policy anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112870 91177308-0d34-0410-b5e6-96231b3b80d8
I think there are good reasons to change this, but in the interests
of short-term stability, make SmallVector<...,0> reserve non-zero
capacity in its constructors. This means that SmallVector<...,0>
uses more memory than SmallVector<...,1> and should really only be
used (unless/until this workaround is removed) by clients that
care about using SmallVector with an incomplete type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112147 91177308-0d34-0410-b5e6-96231b3b80d8
- Cache used characters in a bitset to reduce memory overhead to just 32 bytes.
- On my core2 this code is faster except when the checked string was very short
(smaller than the list of delimiters).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111817 91177308-0d34-0410-b5e6-96231b3b80d8
- Respect find_first_of(char's From parameter instead of silently dropping it.
- Prefer std::string() to std::string("")
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111814 91177308-0d34-0410-b5e6-96231b3b80d8
We must complete the DFS, otherwise we might miss needed phi-defs, and
prematurely color live ranges with a non-dominating value.
This is not a big deal since we get to color more of the CFG and the next
mapValue call will be faster.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111397 91177308-0d34-0410-b5e6-96231b3b80d8
implementations of equality comparison and hash computation. This
can be used to optimize node lookup by avoiding creating lots of
temporary ID values just for hashing and comparison purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111130 91177308-0d34-0410-b5e6-96231b3b80d8
target triple and straightens it out. This does less than gcc's script
config.sub, for example it turns i386-mingw32 into i386--mingw32 not
i386-pc-mingw32, but it does a decent job of turning funky triples into
something that the rest of the Triple class can understand. The plan
is to use this to canonicalize triple's when they are first provided
by users, and have the rest of LLVM only deal with canonical triples.
Once this is done the special case workarounds in the Triple constructor
can be removed, making the class more regular and easier to use. The
comments and unittests for the Triple class are already adjusted in this
patch appropriately for this brave new world of increased uniformity.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110909 91177308-0d34-0410-b5e6-96231b3b80d8
handles with a pointer to the containing map. When a map is copied, these
pointers need to be corrected to point to the new map. If not, then consider
the case of a map M1 which maps a value V to something. Create a copy M2 of
M1. At this point there are two value handles on V, one representing V as a
key in M1, the other representing V as a key in M2. But both value handles
point to M1 as the containing map. Now delete V. The value handles remove
themselves from their containing map (which destroys them), but only the first
value handle is successful: the second one cannot remove itself from M1 as
(once the first one has removed itself) there is nothing there to remove; it
is therefore not destroyed. This causes an assertion failure "All references
to V were not removed?".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109851 91177308-0d34-0410-b5e6-96231b3b80d8
with an existing allocator. The interesting use case of this
is that it allows "StringMap<whatever, BumpPtrAllocator&>" for
when you want to allocate out of a preexisting bump pointer
allocator owned by someone else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109213 91177308-0d34-0410-b5e6-96231b3b80d8
replaced by a bigger array in SmallPtrSet (by overridding it), instead just use a
pointer to the start of the storage, and have SmallPtrSet pass in the value to use.
This has the disadvantage that SmallPtrSet becomes bigger by one pointer. It has
the advantage that it no longer uses tricky C++ rules, and is clearly correct while
I'm not sure the previous version was. This was inspired by g++-4.6 pointing out
that SmallPtrSetImpl was writing off the end of SmallArray, which it was. Since
SmallArray is replaced with a bigger array in SmallPtrSet, the write was still to
valid memory. But it was writing off the end of the declared array type - sounds
kind of dubious to me, like it sounded dubious to g++-4.6. Maybe g++-4.6 is wrong
and this construct is perfectly valid and correctly compiled by all compilers, but
I think it is better to avoid the whole can of worms by avoiding this construct.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107285 91177308-0d34-0410-b5e6-96231b3b80d8
SmallArray[SmallSize] in the SmallPtrSetIteratorImpl, and this is
one off the end of the array. For those who care, right now gcc
warns about writing off the end because it is confused about the
declaration of SmallArray as having length 1 in the parent class
SmallPtrSetIteratorImpl. However if you tweak code to unconfuse
it, then it still warns about writing off the end of the array,
because of this buffer overflow. In short, even with this fix
gcc-4.6 will warn about writing off the end of the array, but now
that is only because it is confused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@107200 91177308-0d34-0410-b5e6-96231b3b80d8
the Profile method. Currently this only works with the default FoldingSetTraits
implementation.
The point of this is to allow nodes to not store context values which are only
used during profiling. A better solution would thread this value through the
folding algorithms, but then those would need to be (1) templated and
(2) non-opaque.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105819 91177308-0d34-0410-b5e6-96231b3b80d8
'class llvm::DAGDeltaAlgorithm' has virtual functions and accessible non-virtual destructor
Not sure if this is the best solution, but this class has state and some of the
classes that inherit from it also do, so it looks appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105675 91177308-0d34-0410-b5e6-96231b3b80d8
- This can give substantial speedups in the delta process for inputs we can construct dependency information for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@105612 91177308-0d34-0410-b5e6-96231b3b80d8
