Fix more clang-tidy cleanups in mlir/ (NFC)

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differenti

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

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

show more ...

[mlir] MicroOptimize a few hot StorageUniquer code paths

* Sprinkle `inline` on a few small and hot hashing/uniquing methods
* Use the faster DenseMapInfo hash functions instead of
llvm::hash_val

[mlir] MicroOptimize a few hot StorageUniquer code paths

* Sprinkle `inline` on a few small and hot hashing/uniquing methods
* Use the faster DenseMapInfo hash functions instead of
llvm::hash_value.

This provides a speed up of a few percent in workloads with lots of
attributes.

show more ...

[mlir][StorageUniquer] Properly call the destructor on non-trivially destructible storage instances

This allows for storage instances to store data that isn't uniqued in the context, or contain othe

[mlir][StorageUniquer] Properly call the destructor on non-trivially destructible storage instances

This allows for storage instances to store data that isn't uniqued in the context, or contain otherwise non-trivial logic, in the rare situations that they occur. Storage instances with trivial destructors will still have their destructor skipped. A consequence of this is that the storage instance definition must be visible from the place that registers the type.

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

show more ...

[mlir][StorageUniquer] Refactor parametric storage to use sharded dense sets

This revisions implements sharding in the storage of parametric instances to decrease lock contention by sharding out the

[mlir][StorageUniquer] Refactor parametric storage to use sharded dense sets

This revisions implements sharding in the storage of parametric instances to decrease lock contention by sharding out the allocator/mutex/etc. to use for a specific storage instance based on the hash key. This is a somewhat common approach to reducing lock contention on data structures, and is used by the concurrent hashmaps provided by folly/java/etc. For several compilations tested, this removed all/most lock contention from profiles and reduced compile time by several seconds.

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

show more ...

[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects.

(Note: This is a reland of D82597)

This class allows for defining thread local objects that have a set non

[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects.

(Note: This is a reland of D82597)

This class allows for defining thread local objects that have a set non-static lifetime. This internals of the cache use a static thread_local map between the various different non-static objects and the desired value type. When a non-static object destructs, it simply nulls out the entry in the static map. This will leave an entry in the map, but erase any of the data for the associated value. The current use cases for this are in the MLIRContext, meaning that the number of items in the static map is ~1-2 which aren't particularly costly enough to warrant the complexity of pruning. If a use case arises that requires pruning of the map, the functionality can be added.

This is especially useful in the context of MLIR for implementing thread-local caching of context level objects that would otherwise have very high lock contention. This revision adds a thread local cache in the MLIRContext for attributes, identifiers, and types to reduce some of the locking burden. This led to a speedup of several seconds when compiling a somewhat large mlir module.

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

show more ...

Add more explicit error message when creating a type or attribute for an unregistered dialect (NFC)

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

[mlir] Remove the use of "kinds" from Attributes and Types

This greatly simplifies a large portion of the underlying infrastructure, allows for lookups of singleton classes to be much more efficient

[mlir] Remove the use of "kinds" from Attributes and Types

This greatly simplifies a large portion of the underlying infrastructure, allows for lookups of singleton classes to be much more efficient and always thread-safe(no locking). As a result of this, the dialect symbol registry has been removed as it is no longer necessary.

For users broken by this change, an alert was sent out(https://llvm.discourse.group/t/removing-kinds-from-attributes-and-types) that helps prevent a majority of the breakage surface area. All that should be necessary, if the advice in that alert was followed, is removing the kind passed to the ::get methods.

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

show more ...

Revert "[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects."

This reverts commit 9f24640b7e6e61b0f293c724155a90a5e446dd7a.

We hit some dead-locks on thread ex

Revert "[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects."

This reverts commit 9f24640b7e6e61b0f293c724155a90a5e446dd7a.

We hit some dead-locks on thread exit in some configurations: TLS exit handler is taking a lock.
Temporarily reverting this change as we're debugging what is going on.

show more ...

[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects.

This class allows for defining thread local objects that have a set non-static lifetime. This internals of

[mlir] Add a utility class, ThreadLocalCache, for storing non static thread local objects.

This class allows for defining thread local objects that have a set non-static lifetime. This internals of the cache use a static thread_local map between the various different non-static objects and the desired value type. When a non-static object destructs, it simply nulls out the entry in the static map. This will leave an entry in the map, but erase any of the data for the associated value. The current use cases for this are in the MLIRContext, meaning that the number of items in the static map is ~1-2 which aren't particularly costly enough to warrant the complexity of pruning. If a use case arises that requires pruning of the map, the functionality can be added.

This is especially useful in the context of MLIR for implementing thread-local caching of context level objects that would otherwise have very high lock contention. This revision adds a thread local cache in the MLIRContext for attributes, identifiers, and types to reduce some of the locking burden. This led to a speedup of several hundred miliseconds when compiling a conversion pass on a very large mlir module(>300K operations).

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

show more ...

[mlir] Refactor StorageUniquer to require registration of possible storage types

This allows for bucketing the different possible storage types, with each bucket having its own allocator/mutex/insta

[mlir] Refactor StorageUniquer to require registration of possible storage types

This allows for bucketing the different possible storage types, with each bucket having its own allocator/mutex/instance map. This greatly reduces the amount of lock contention when multi-threading is enabled. On some non-trivial .mlir modules (>300K operations), this led to a compile time decrease of a single conversion pass by around half a second(>25%).

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

show more ...

[mlir] Support for mutable types

Introduce support for mutable storage in the StorageUniquer infrastructure.
This makes MLIR have key-value storage instead of just uniqued key storage. A
storage ins

[mlir] Support for mutable types

Introduce support for mutable storage in the StorageUniquer infrastructure.
This makes MLIR have key-value storage instead of just uniqued key storage. A
storage instance now contains a unique immutable key and a mutable value, both
stored in the arena allocator that belongs to the context. This is a
preconditio for supporting recursive types that require delayed initialization,
in particular LLVM structure types. The functionality is exercised in the test
pass with trivial self-recursive type. So far, recursive types can only be
printed in parsed in a closed type system. Removing this restriction is left
for future work.

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

show more ...

[mlir] Add a new context flag for disabling/enabling multi-threading

This is useful for several reasons:
* In some situations the user can guarantee that thread-safety isn't necessary and don't want

[mlir] Add a new context flag for disabling/enabling multi-threading

This is useful for several reasons:
* In some situations the user can guarantee that thread-safety isn't necessary and don't want to pay the cost of synchronization, e.g., when parsing a very large module.

* For things like logging threading is not desirable as the output is not guaranteed to be in stable order.

This flag also subsumes the pass manager flag for multi-threading.

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

show more ...

[mlir][StorageUniquer] Replace all usages of std::function with function_ref.

Summary: std::function has a notoriously large amount of malloc traffic, whereas function_ref is a cheaper and more effi

[mlir][StorageUniquer] Replace all usages of std::function with function_ref.

Summary: std::function has a notoriously large amount of malloc traffic, whereas function_ref is a cheaper and more efficient alternative.

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

show more ...

Mass update the MLIR license header to mention "Part of the LLVM project"

This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.

Adjust License.txt file to use the LLVM license

PiperOrigin-RevId: 286906740

NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared in `mlir` namespace.

Aside from being cleaner, this also makes the codebase more consistent.

PiperOrigin-RevId: 286206974

Add missing include to llvm Allocator.h

This header is not self-contained otherwise.

PiperOrigin-RevId: 275651582

Fully qualify DenseMap.

PiperOrigin-RevId: 261325481

Remove unnecessary C++ specifier in CPP files. NFC.

These are only required in .h files to disambiguate between C and C++ header files.

--

PiperOrigin-RevId: 248219135

Refactor Attribute uniquing to use StorageUniquer instead of being hard coded in the MLIRContext. This allows for attributes to be uniqued similarly to types. This is the second step towards allowing

Refactor Attribute uniquing to use StorageUniquer instead of being hard coded in the MLIRContext. This allows for attributes to be uniqued similarly to types. This is the second step towards allowing dialects to define attributes.

--

PiperOrigin-RevId: 245974705

show more ...

Refactor the generic storage object uniquing functionality from TypeUniquer into its own class 'StorageUniquer'. This is the first step in supporting dialect extensible attributes.

--

PiperOrigin-R

Refactor the generic storage object uniquing functionality from TypeUniquer into its own class 'StorageUniquer'. This is the first step in supporting dialect extensible attributes.

--

PiperOrigin-RevId: 245358744

show more ...