DenseMap: support enum class keys (#95972)

Implemented using std::underlying_type.

[ADT] Add C++17-style insert_or_assign for DenseMap (#94151)

add C++17-style insert_or_assign for DenseMap

close: #94115

[ADT] refactor MoveOnly type in ADT unittest (#94421)

context:
https://github.com/llvm/llvm-project/pull/94151#pullrequestreview-2097098530

[unittest] teach gTest to print entries of DenseMap as pairs

When an assertion like the following fails:
EXPECT_THAT(map, ElementsAre(Pair("p", "nullable"))));
Error message before:
Actual: {

[unittest] teach gTest to print entries of DenseMap as pairs

When an assertion like the following fails:
EXPECT_THAT(map, ElementsAre(Pair("p", "nullable"))));
Error message before:
Actual: { 40-byte object <E8-A5 9C-7F 25-37 00-00 58-7E 51-51 D0-7F 00-00 00-00 00-00 00-00 00-00 01-00 00-00 00-00 00-00 00-DA C7-7F 25-37 00-00> }
After:
Actual: { ("p", "nonnull") }

It is not ideal that we need to refer directly to DenseMapPair inside the
internal namespace, but I believe the practical maintenance risk is low.
This change is covered by DenseMap's unittests, as we've covered SmallString etc
in the past.

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

show more ...

[llvm] Split out DenseMapInfo<variant> specialization

Remove the `DenseMapInfo<std::variant<Ts...>>` variant out from
`llvm/ADT/DenseMapInfo.h` into a separate header
`llvm/ADT/DenseMapInfoVariant.h

[llvm] Split out DenseMapInfo<variant> specialization

Remove the `DenseMapInfo<std::variant<Ts...>>` variant out from
`llvm/ADT/DenseMapInfo.h` into a separate header
`llvm/ADT/DenseMapInfoVariant.h`

This allows us to remove the `<variant>` include, which is being
transitively and unncessary included in all translation units that
include `llvm/ADT/DenseMap.h`.

There have been similar changes to move out specializations for

* `APInt.h` fd7e309e02fd226b0390888388ed732608e52c73 and
* `StringRef.h`/`ArrayRef.h`
983565a6fe4a9f40c7caf82b65c650c20dbcc104

to reduce the compilation time. As we are unable to move the
specialization into `<variant>`, we create a separate
`DenseMapInfoVariant.h` header that can be used by anyone who needs this
specialization.

This reduces the total number of preprocessing tokens across the LLVM
source files in lib from (roughly) 1,964,876,961 to 1,936,551,496 - a
reduction of ~1.44%. This should result in a small improvement in
compilation time.

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

show more ...

[ADT] Fix DenseMapInfo<variant>::isEqual to delegate to DenseMapInfo, not ==

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

[ADT] Implement {DenseMap,MapVector,StringMap}::contains

This patch implements the C++20-style contains() for DenseMap,
MapVector, and StringMap.

With this patch, every set and map container type t

[ADT] Implement {DenseMap,MapVector,StringMap}::contains

This patch implements the C++20-style contains() for DenseMap,
MapVector, and StringMap.

With this patch, every set and map container type that has count()
also has contains().

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

show more ...

[ADT] Fix tests for `StringMap::at` and `DenseMap::at`

These methods won't assert for release build.

[ADT] Add `at` method (assertive lookup) to DenseMap and StringMap

This patch makes it easier for users when they want to use validated
lookup on DenseMap/StringMap as a composable C++ expression. F

[ADT] Add `at` method (assertive lookup) to DenseMap and StringMap

This patch makes it easier for users when they want to use validated
lookup on DenseMap/StringMap as a composable C++ expression. For
instance:

```
// instead of
if (auto val = map.lookup(key))
return val;
assert("...");

// we can write
return map.at(key);
```

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

show more ...

[llvm] Call reserve before push_back in a loop

It is generally good practice, if you know how big the vector is going to be in the end, to reserve before continually calling "push_back" or "emplace_

[llvm] Call reserve before push_back in a loop

It is generally good practice, if you know how big the vector is going to be in the end, to reserve before continually calling "push_back" or "emplace_back"

Reviewed By: MaskRay

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

show more ...

Reland "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c.

This relands commit
1834a310d060d55748ca38d4ae0482864c2047d8.

Differential R

Reland "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c.

This relands commit
1834a310d060d55748ca38d4ae0482864c2047d8.

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

show more ...

Revert "[llvm][NFC] Use c++17 style variable type traits"

This reverts commit 1834a310d060d55748ca38d4ae0482864c2047d8.

[llvm][NFC] Use c++17 style variable type traits

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

[llvm][NFC] Use c++17 style variable type traits

This was done as a test for D137302 and it makes sense to push these changes

Reviewed By: dblaikie

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

show more ...

[llvm][Support] Add DenseMapInfo for std::variant

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

Fix assertion in SmallDenseMap constructor with reserve from non-power-of-2 buckets count

`SmallDenseMap` constructor with reserve gets an arbitrary `NumInitBuckets` value and passes it below to `in

Fix assertion in SmallDenseMap constructor with reserve from non-power-of-2 buckets count

`SmallDenseMap` constructor with reserve gets an arbitrary `NumInitBuckets` value and passes it below to `init` method.

If `NumInitBuckets` is greater then `InlineBuckets`, then `SmallDenseMap` initializes to large representation passing `NumInitBuckets` below to `DenseMap` initialization. `DenseMap::initEmpty` method asserts that initial buckets count must be a power of 2.

Proposed solution is to update `NumInitBuckets` value in `SmallDenseMap` constructor till the next power of 2. It should satisfy both `DenseMap` preconditions and required minimum buckets count for reservation.

Reviewed By: atrick

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

show more ...

[llvm] Add a SFINAE template parameter to DenseMapInfo

This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partia

[llvm] Add a SFINAE template parameter to DenseMapInfo

This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partial
specializations that support all Attribute, Op, and Type classes without
needing to specialize DenseMapInfo for each individual class.

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

show more ...

[ADT] Add initializer_list constructor to SmallDenseMap

Make it easier to initialize small maps inline. Note that DenseMap already has an initializer_list constructor.

Reviewed By: dblaikie

Differ

[ADT] Add initializer_list constructor to SmallDenseMap

Make it easier to initialize small maps inline. Note that DenseMap already has an initializer_list constructor.

Reviewed By: dblaikie

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

show more ...

Put back the trailing commas on TYPED_TEST_SUITE

This avoids a -pedantic warning:
warning: ISO C++11 requires at least one argument for the "..." in a variadic macro

See also https://github.com/goo

Put back the trailing commas on TYPED_TEST_SUITE

This avoids a -pedantic warning:
warning: ISO C++11 requires at least one argument for the "..." in a variadic macro

See also https://github.com/google/googletest/issues/2271

show more ...

Bump googletest to 1.10.0

[ADT] Allow K to be incomplete during DenseMap<K*, V> instantiation

DenseMap requires two sentinel values for keys: empty and tombstone
values. To avoid undefined behavior, LLVM aligns the two senti

[ADT] Allow K to be incomplete during DenseMap<K*, V> instantiation

DenseMap requires two sentinel values for keys: empty and tombstone
values. To avoid undefined behavior, LLVM aligns the two sentinel
pointers to alignof(T). This requires T to be complete, which is
needlessly restrictive.

Instead, assume that DenseMap pointer keys have a maximum alignment of
4096, and use the same sentinel values for all pointer keys. The new
sentinels are:
empty: static_cast<uintptr_t>(-1) << 12
tombstone: static_cast<uintptr_t>(-2) << 12

These correspond to the addresses of -4096 and -8192. Hopefully, such a
key is never inserted into a DenseMap.

I encountered this while looking at making clang's SourceManager not
require FileManager.h, but it has several maps keyed on classes defined
in FileManager.h. FileManager depends on various LLVM FS headers, which
cumulatively take ~200ms to parse, and are generally not needed.

Reviewed By: hans

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

show more ...

[ADT] Fix SmallDenseMap assertion with large InlineBuckets

Fixes issue encountered in D56362, where I tried to use a
SmallSetVector<Instruction*, 128> with an excessively large number
of inline elem

[ADT] Fix SmallDenseMap assertion with large InlineBuckets

Fixes issue encountered in D56362, where I tried to use a
SmallSetVector<Instruction*, 128> with an excessively large number
of inline elements. This triggers an "Must allocate more buckets
than are inline" assertion inside allocateBuckets() under certain
usage patterns.

The issue is as follows: The grow() method is used either to grow
the map, or to rehash it and remove tombstones. The latter is done
if the fraction of empty (non-used, non-tombstone) elements is
below 1/8. In this case grow() is invoked with the current number
of buckets.

This is currently incorrectly handled for dense maps using the small
rep. The current implementation will switch them over to the large
rep, which violates the invariant that the large rep is only used
if there are more than InlineBuckets buckets.

This patch fixes the issue by staying in the small rep and only
moving the buckets. An alternative, if we do want to switch to the
large rep in this case, would be to relax the assertion in
allocateBuckets().

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

show more ...

[ADT] Remove MSVC-only "no two-phase name lookup" typename path.

Now that we've dropped VS2015 support (D64326) we can use the regular codepath as VS2017+ correctly handles it

llvm-svn: 365502

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

[ADT] Adds equality operators for DenseMap and DenseSet, and an initializer_list
constructor for DenseMap (DenseSet already had an initializer_list constructor).

These changes make it easier to migr

[ADT] Adds equality operators for DenseMap and DenseSet, and an initializer_list
constructor for DenseMap (DenseSet already had an initializer_list constructor).

These changes make it easier to migrate existing code that uses std::map and
std::set (which support initializer_list construction and equality comparison)
to DenseMap and DenseSet.

llvm-svn: 344522

show more ...

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they ar

Remove \brief commands from doxygen comments.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

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

llvm-svn: 331272

show more ...