[llvm] Use *{Map,Set}::contains (NFC)

Fixup Asserts+!AbiBreakingChecks fallout from db33f85c7124

[IR] Support efficient AssertingVH/PoisoningVH lookup

Currently, there doesn't seem to be any way to look up a Value*
in a map/set indexed by AssertingVH/PoisoningVH, without creating
a value handle

[IR] Support efficient AssertingVH/PoisoningVH lookup

Currently, there doesn't seem to be any way to look up a Value*
in a map/set indexed by AssertingVH/PoisoningVH, without creating
a value handle -- which is fairly expensive, because it involves
adding the value handle to the use list and immediately removing
it again. Using find_as(Value *) does not work (and is in fact
worse than just using find(Value *)), because it will end up
creating multiple value handles during the lookup itself.

For AssertingVH, address this by simply using DenseMapInfo<T *>
instead of manually implementing something. The AssertingVH<T>
will now get coerced to T*, rather than the other way around.

For PoisoningVH, add extra overloads of getHashValue() and
isEqual() that accept a T* argument.

This allows using find_as(Value *) to perform efficient lookups
in assertion-enabled builds.

Differential Revision: https://reviews.llvm.org/D81793

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Add a new WeakVH value handle; NFC

This relands r301425.

llvm-svn: 301813

Rename WeakVH to WeakTrackingVH; NFC

This relands r301424.

llvm-svn: 301812

Emulate TrackingVH using WeakVH

Summary:
This frees up one slot in the HandleBaseKind enum, which I will use
later to add a new kind of value handle. The size of the
HandleBaseKind enum is importan

Emulate TrackingVH using WeakVH

Summary:
This frees up one slot in the HandleBaseKind enum, which I will use
later to add a new kind of value handle. The size of the
HandleBaseKind enum is important because we store a HandleBaseKind in
the low two bits of a (in the worst case) 4 byte aligned pointer.

Reviewers: davide, chandlerc

Subscribers: mcrosier, llvm-commits

Differential Revision: https://reviews.llvm.org/D32634

llvm-svn: 301809

show more ...

Reverts commit r301424, r301425 and r301426

Commits were:

"Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts"
"Add a new WeakVH value handle; NFC"
"Rename WeakVH to WeakTracking

Reverts commit r301424, r301425 and r301426

Commits were:

"Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts"
"Add a new WeakVH value handle; NFC"
"Rename WeakVH to WeakTrackingVH; NFC"

The changes assumed pointers are 8 byte aligned on all architectures.

llvm-svn: 301429

show more ...

Add a new WeakVH value handle; NFC

Summary:
WeakVH nulls itself out if the value it was tracking gets deleted, but
it does not track RAUW.

Reviewers: dblaikie, davide

Subscribers: mcrosier, llvm-c

Add a new WeakVH value handle; NFC

Summary:
WeakVH nulls itself out if the value it was tracking gets deleted, but
it does not track RAUW.

Reviewers: dblaikie, davide

Subscribers: mcrosier, llvm-commits

Differential Revision: https://reviews.llvm.org/D32267

llvm-svn: 301425

show more ...

Rename WeakVH to WeakTrackingVH; NFC

Summary:
I plan to use WeakVH to mean "nulls itself out on deletion, but does
not track RAUW" in a subsequent commit.

Reviewers: dblaikie, davide

Reviewed By:

Rename WeakVH to WeakTrackingVH; NFC

Summary:
I plan to use WeakVH to mean "nulls itself out on deletion, but does
not track RAUW" in a subsequent commit.

Reviewers: dblaikie, davide

Reviewed By: davide

Subscribers: arsenm, mehdi_amini, mcrosier, mzolotukhin, jfb, llvm-commits, nhaehnle

Differential Revision: https://reviews.llvm.org/D32266

llvm-svn: 301424

show more ...

[PM] Introduce a PoisoningVH as a (more expensive) alternative to
AssertingVH that delays any reported error until the handle is *used*.

This allows data structures to contain handles which become d

[PM] Introduce a PoisoningVH as a (more expensive) alternative to
AssertingVH that delays any reported error until the handle is *used*.

This allows data structures to contain handles which become dangling
provided the data structure is cleaned up afterward rather than used for
anything interesting.

The implementation is moderately horrible in part because it works to
leave AssertingVH in place, undisturbed. If at some point there is
consensus that this is simply how AssertingVH should be used, it can be
substantially simplified.

This remains a boring pointer in a non-asserts build as you would
expect. The only place we pay cost is in asserts builds.

I plan to use this as a basis for replacing the asserting VHs that
currently dangle in the new PM until invalidation occurs in both LVI and
SCEV.

Differential Revision: https://reviews.llvm.org/D29061

llvm-svn: 292925

show more ...

Remove every uses of getGlobalContext() in LLVM (but the C API)

At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
dest

Remove every uses of getGlobalContext() in LLVM (but the C API)

At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.

This is the first part of http://reviews.llvm.org/D19094

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266379

show more ...

-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11

Various value handles needed to be copy constructible and copy
assignable (mostly for their use in Dense

-Wdeprecated-clean: Fix cases of violating the rule of 5 in ways that are deprecated in C++11

Various value handles needed to be copy constructible and copy
assignable (mostly for their use in DenseMap). But to avoid an API that
might allow accidental slicing, make these members protected in the base
class and make derived classes final (the special members become
implicitly public there - but disallowing further derived classes that
might be sliced to the intermediate type).

Might be worth having a warning a bit like -Wnon-virtual-dtor that
catches public move/copy assign/ctors in classes with virtual functions.
(suppressable in the same way - by making them protected in the base,
and making the derived classes final) Could be fancier and only diagnose
them when they're actually called, potentially.

Also allow a few default implementations where custom implementations
(especially with non-standard return types) were implemented.

llvm-svn: 243909

show more ...

Replace std::auto_ptr with std::unique_ptr

std::auto_ptr is deprecated in GCC 5.0, and we are already using
std::unique_ptr all over the place.

Patch by Xan López.

llvm-svn: 235479

Use 'override/final' instead of 'virtual' for overridden methods

The patch is generated using clang-tidy misc-use-override check.

This command was used:

tools/clang/tools/extra/clang-tidy/tool/r

Use 'override/final' instead of 'virtual' for overridden methods

The patch is generated using clang-tidy misc-use-override check.

This command was used:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' \
-j=32 -fix -format

http://reviews.llvm.org/D8925

llvm-svn: 234679

show more ...

[C++11] Use 'nullptr'.

llvm-svn: 210442

Replace OwningPtr<T> with std::unique_ptr<T>.

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 ha

Replace OwningPtr<T> with std::unique_ptr<T>.

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

show more ...

[Modules] Move ValueHandle into the IR library where Value itself lives.

Move the test for this class into the IR unittests as well.

This uncovers that ValueMap too is in the IR library. Ironically

[Modules] Move ValueHandle into the IR library where Value itself lives.

Move the test for this class into the IR unittests as well.

This uncovers that ValueMap too is in the IR library. Ironically, the
unittest for ValueMap is useless in the Support library (honestly, so
was the ValueHandle test) and so it already lives in the IR unittests.
Mmmm, tasty layering.

llvm-svn: 202821

show more ...