Commit Graph

18 Commits

Author SHA1 Message Date
Chandler Carruth
255f89faee Sort the #include lines for the include/... tree with the script.
AKA: Recompile *ALL* the source code!

This one went much better. No manual edits here. I spot-checked for
silliness and grep-checked for really broken edits and everything seemed
good. It all still compiles. Yell if you see something that looks goofy.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169133 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-03 17:02:12 +00:00
Craig Topper
fc601db2ed Mark unimplemented copy constructors and copy assignment operators as LLVM_DELETED_FUNCTION.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164014 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-17 06:31:17 +00:00
Benjamin Kramer
9e7e04823c Disambiguate call to operator==.
clang++ and msvc happily had no problem with it but g++ refuses to compile.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157126 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-19 19:32:11 +00:00
Benjamin Kramer
96edb648e2 ValueMap: Use DenseMap's find_as mechanism to reduce use list churn.
Otherwise just looking up a value in the map requires creating a VH, adding it to the use lists and destroying it again.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157124 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-19 19:15:32 +00:00
Benjamin Kramer
4e58263459 DenseMap: Perform the pod-like object optimization when the value type is POD-like, not the DenseMapInfo for it.
Purge now unused template arguments. This has been broken since r91421. Patch by Lubos Lunak!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154170 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-06 10:43:44 +00:00
Michael J. Spencer
1f6efa3996 Merge System into Support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120298 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-29 18:16:10 +00:00
Dan Gohman
e3955df639 Make the iterator form of erase return void, since it always succeeds,
and since this is what std::map and std::set do.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112701 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-01 14:00:35 +00:00
Duncan Sands
fffe6cf084 Remove the ValueMap operator=, which was wrong (it did't correct the
Map pointers of any contained ValueMapCallbackVH's) and unused.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110577 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-09 16:44:56 +00:00
Duncan Sands
3850f5ceda Remove the ValueMap copy constructor. It's not used anywhere,
and removing it catches the mistake of passing a ValueMap by
copy rather than by reference.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110549 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-08 12:57:48 +00:00
Duncan Sands
bcc2393369 Fix the ValueMap copy constructor. The issue is that the map keys are value
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
2010-07-30 05:49:32 +00:00
Duncan Sands
978bb87f88 In commit 91421, isPod was changed from false to true for these value handles.
Change it back again: destructors and constructors need to be run.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109498 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-27 09:09:05 +00:00
Eric Christopher
dd6f86a28f Silence some unused variable warnings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@106778 91177308-0d34-0410-b5e6-96231b3b80d8
2010-06-24 20:14:34 +00:00
Chris Lattner
4bbf4ee149 Remove isPod() from DenseMapInfo, splitting it out to its own
isPodLike type trait.  This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91421 91177308-0d34-0410-b5e6-96231b3b80d8
2009-12-15 07:26:43 +00:00
Mike Stump
fe134fe9e5 Fix VS build, patch by Marius Wachtler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85198 91177308-0d34-0410-b5e6-96231b3b80d8
2009-10-27 02:17:51 +00:00
Jeffrey Yasskin
4ab74cdc12 Fix stylistic and documentation problems in ValueMap found by Nick Lewycky and
Evan Cheng.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84967 91177308-0d34-0410-b5e6-96231b3b80d8
2009-10-23 20:54:00 +00:00
Jeffrey Yasskin
71a5c22c2b Try r84890 again (adding ValueMap<>), now that I've tested the compile on
gcc-4.4.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84902 91177308-0d34-0410-b5e6-96231b3b80d8
2009-10-22 22:11:22 +00:00
Jeffrey Yasskin
a84c9db467 Revert r84890, which broke the linux build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84892 91177308-0d34-0410-b5e6-96231b3b80d8
2009-10-22 20:23:43 +00:00
Jeffrey Yasskin
e0a234029b Add a ValueMap<ValueOrSubclass*, T> type. ValueMap<Value*, T> is safe to use
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.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84890 91177308-0d34-0410-b5e6-96231b3b80d8
2009-10-22 20:10:20 +00:00