Remove redundant string initialization (NFC)

Identified with readability-redundant-string-init.

Use value_or instead of getValueOr (NFC)

[mlir:Pass] Add support for op-agnostic pass managers

This commit refactors the current pass manager support to allow for
operation agnostic pass managers. This allows for a series of passes
to be e

[mlir:Pass] Add support for op-agnostic pass managers

This commit refactors the current pass manager support to allow for
operation agnostic pass managers. This allows for a series of passes
to be executed on any viable pass manager root operation, instead
of one specific operation type. Op-agnostic/generic pass managers
only allow for adding op-agnostic passes.

These types of pass managers are extremely useful when constructing
pass pipelines that can apply to many different types of operations,
e.g., the default inliner simplification pipeline. With the advent of
interface/trait passes, this support can be used to define FunctionOpInterface
pass managers, or other pass managers that effectively operate on
specific interfaces/traits/etc (see #52916 for an example).

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

show more ...

[mlir][NFC] Drop a few unnecessary includes from Pass.h

[mlir] Allow for using OpPassManager in pass options

This significantly simplifies the boilerplate necessary for passes
to define nested pass pipelines.

Differential Revision: https://reviews.llvm.

[mlir] Allow for using OpPassManager in pass options

This significantly simplifies the boilerplate necessary for passes
to define nested pass pipelines.

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

show more ...

[mlir] Fix missing verification after running an OpToOpAdaptorPass

The current decision of when to run the verifier is running on the
assumption that nested passes can't affect the validity of the p

[mlir] Fix missing verification after running an OpToOpAdaptorPass

The current decision of when to run the verifier is running on the
assumption that nested passes can't affect the validity of the parent
operation, which isn't true. Parent operations may attach any number
of constraints on nested operations, which may not necessarily be
captured (or shouldn't be captured) at a smaller granularity.

This commit rectifies this by properly running the verifier after an
OpToOpAdaptor pass. To avoid an explosive increase in compile time,
we only run verification on the parent operation itself. To do this, a
flag to mlir::verify is added to avoid recursive verification if it isn't
desired.

Fixes #54288

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

show more ...

[mlir][Pass] Add support for an InterfacePass and pass filtering based on OperationName

This commit adds a new hook Pass `bool canScheduleOn(RegisteredOperationName)` that
indicates if the given pas

[mlir][Pass] Add support for an InterfacePass and pass filtering based on OperationName

This commit adds a new hook Pass `bool canScheduleOn(RegisteredOperationName)` that
indicates if the given pass can be scheduled on operations of the given type. This makes it
easier to define constraints on generic passes without a) adding conditional checks to
the beginning of the `runOnOperation`, or b) defining a new pass type that forwards
from `runOnOperation` (after checking the invariants) to a new hook. This new hook is
used to implement an `InterfacePass` pass class, that represents a generic pass that
runs on operations of the given interface type.

The PassManager will also verify that passes added to a pass manager can actually be
scheduled on that pass manager, meaning that we will properly error when an Interface
is scheduled on an operation that doesn't actually implement that interface.

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

show more ...

[mlir] Finish removing Identifier from the C++ API

There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. Afte

[mlir] Finish removing Identifier from the C++ API

There have been a few API pieces remaining to allow for a smooth transition for
downstream users, but these have been up for a few months now. After this only
the C API will have reference to "Identifier", but those will be reworked in a followup.

The main updates are:
* Identifier -> StringAttr
* StringAttr::get requires the context as the first parameter
- i.e. `Identifier::get("...", ctx)` -> `StringAttr::get(ctx, "...")`

Reviewed By: mehdi_amini

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

show more ...

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

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

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

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][NFC] Replace references to Identifier with StringAttr

This is part of the replacement of Identifier with StringAttr.

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

Use std::make_unique instead of `new` to reinitalize a unique_ptr (NFC)

Fix a clang-tidy warning.

Add a clear() method on the PassManager (NFC)

This allows to clear an OpPassManager and populated it again with a new
pipeline, while preserving all the other options (including instrumentations).

Add a clear() method on the PassManager (NFC)

This allows to clear an OpPassManager and populated it again with a new
pipeline, while preserving all the other options (including instrumentations).

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

show more ...

Remove unused llvm/Support/Parallel.h from MLIR (NFC)

This header aren't needed anymore: MLIR is using a thread pool
injected in the context instead of a global one.

Fix mismatch between the provisioning of asyncExecutors and the actual thread count currently in the context (NFC)

This fixes an assert in some deployment where the threadpool is
customized.

[mlir] Fix GCC5 build after D104516

GCC5 isn't able to implicitly capture `this` properly in an `auto` lambda.

[mlir] Add a ThreadPool to MLIRContext and refactor MLIR threading usage

This revision refactors the usage of multithreaded utilities in MLIR to use a common
thread pool within the MLIR context, in

[mlir] Add a ThreadPool to MLIRContext and refactor MLIR threading usage

This revision refactors the usage of multithreaded utilities in MLIR to use a common
thread pool within the MLIR context, in addition to a new utility that makes writing
multi-threaded code in MLIR less error prone. Using a unified thread pool brings about
several advantages:

* Better thread usage and more control
We currently use the static llvm threading utilities, which do not allow multiple
levels of asynchronous scheduling (even if there are open threads). This is due to
how the current TaskGroup structure works, which only allows one truly multithreaded
instance at a time. By having our own ThreadPool we gain more control and flexibility
over our job/thread scheduling, and in a followup can enable threading more parts of
the compiler.

* The static nature of TaskGroup causes issues in certain configurations
Due to the static nature of TaskGroup, there have been quite a few problems related to
destruction that have caused several downstream projects to disable threading. See
D104207 for discussion on some related fallout. By having a ThreadPool scoped to
the context, we don't have to worry about destruction and can ensure that any
additional MLIR thread usage ends when the context is destroyed.

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

show more ...

[PassManager] Save compile time by not running the verifier unnecessarily. NFC

This changes the pass manager to not rerun the verifier when a pass says it
didn't change anything or after an OpToOpPa

[PassManager] Save compile time by not running the verifier unnecessarily. NFC

This changes the pass manager to not rerun the verifier when a pass says it
didn't change anything or after an OpToOpPassAdaptor, since neither of those
cases need verification (and if the pass lied, then there will be much larger
semantic problems than will be caught by the verifier).

This maintains behavior in EXPENSIVE_CHECKS mode.

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

show more ...

[mlir] Refactor the implementation of pass crash reproducers

The current implementation has several key limitations and weirdness, e.g local reproducers don't support dynamic pass pipelines, error m

[mlir] Refactor the implementation of pass crash reproducers

The current implementation has several key limitations and weirdness, e.g local reproducers don't support dynamic pass pipelines, error messages don't include the passes that failed, etc. This revision refactors the implementation to support more use cases, and also be much cleaner.

The main change in this revision, aside from moving the implementation out of Pass.cpp and into its own file, is the addition of a crash recovery pass instrumentation. For local reproducers, this instrumentation handles setting up the recovery context before executing each pass. For global reproducers, the instrumentation is used to provide a more detailed error message, containing information about which passes are running and on which operations.

Example of new message:

```
error: Failures have been detected while processing an MLIR pass pipeline
note: Pipeline failed while executing [`TestCrashRecoveryPass` on 'module' operation: @foo]: reproducer generated at `crash-recovery.mlir.tmp`
```

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

show more ...

[MLIR] Factor pass timing out into a dedicated timing manager

This factors out the pass timing code into a separate `TimingManager`
that can be plugged into the `PassManager` from the outside. Users

[MLIR] Factor pass timing out into a dedicated timing manager

This factors out the pass timing code into a separate `TimingManager`
that can be plugged into the `PassManager` from the outside. Users are
able to provide their own implementation of this manager, and use it to
time additional code paths outside of the pass manager. Also allows for
multiple `PassManager`s to run and contribute to a single timing report.

More specifically, moves most of the existing infrastructure in
`Pass/PassTiming.cpp` into a new `Support/Timing.cpp` file and adds a
public interface in `Support/Timing.h`. The `PassTiming` instrumentation
becomes a wrapper around the new timing infrastructure which adapts the
instrumentation callbacks to the new timers.

Reviewed By: rriddle, lattner

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

show more ...

[mlir] Tune error message for assertion.

This assertion can fire in the case of different contexts as well, which
is not difficult to do from Python bindings, for example.

[mlir][Pass] Coalesce dynamic pass pipelines before running

This was missed when dynamic pass pipelines were added, and is necessary for maximizing the performance/parallelism potential of the pass

[mlir][Pass] Coalesce dynamic pass pipelines before running

This was missed when dynamic pass pipelines were added, and is necessary for maximizing the performance/parallelism potential of the pass pipeline.

show more ...

Enable `Pass::initialize()` to fail by returning a LogicalResult

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

[mlir] avoid exposing mutable DialectRegistry from MLIRContext

MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional d

[mlir] avoid exposing mutable DialectRegistry from MLIRContext

MLIRContext allows its users to access directly to the DialectRegistry it
contains. While sometimes useful for registering additional dialects on an
already existing context, this breaks the encapsulation by essentially giving
raw accesses to a part of the context's internal state. Remove this mutable
access and instead provide a method to append a given DialectRegistry to the
one already contained in the context. Also provide a shortcut mechanism to
construct a context from an already existing registry, which seems to be a
common use case in the wild. Keep read-only access to the registry contained in
the context in case it needs to be copied or used for constructing another
context.

With this change, DialectRegistry is no longer concerned with loading the
dialects and deciding whether to invoke delayed interface registration. Loading
is concentrated in the MLIRContext, and the functionality of the registry
better reflects its name.

Depends On D96137

Reviewed By: mehdi_amini

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

show more ...