Simplify the remaining ones a bit.

llvm-svn: 203249

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

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

access to it on all host toolchains.

llvm-svn: 202642

llvm-svn: 198330

Suggested by Aaron Ballman.

llvm-svn: 198288

Stopgap measure until we can just use static_assert().

llvm-svn: 198273

library rename.

llvm-svn: 171747

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

llvm-svn: 169250

Accidentally left out since r145214/r145217.

llvm-svn: 146356

llvm-svn: 129271

llvm-svn: 119606

This is because of bug 331418 on Microsoft Connect.

llvm-svn: 119600

to link in "core".

llvm-svn: 114831

and removing it catches the mistake of passing a ValueMap by
copy rather than by reference.

llvm-svn: 110549

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?".

llvm-svn: 109851

llvm-svn: 108048

llvm-svn: 101689

fixes PR5395.

llvm-svn: 89385

llvm-svn: 85254

Evan Cheng.

llvm-svn: 84967

gcc-4.4.

llvm-svn: 84902

llvm-svn: 84892

even when keys get RAUWed and deleted during its lifetime. By default the keys
act like WeakVHs, but users can pass a third template parameter to configure
how updates work and whether to do anything beyond updating the map on each
action.

It's also possible to automatically acquire a lock around ValueMap updates
triggered by RAUWs and deletes, to support the ExecutionEngine.

llvm-svn: 84890