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

This is part of the replacement of Identifier with StringAttr.

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

[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][Inliner] Refactor the inliner to use nested pass pipelines instead of just canonicalization

Now that passes have support for running nested pipelines, the inliner can now allow for users to p

[mlir][Inliner] Refactor the inliner to use nested pass pipelines instead of just canonicalization

Now that passes have support for running nested pipelines, the inliner can now allow for users to provide proper nested pipelines to use for optimization during inlining. This revision also changes the behavior of optimization during inlining to optimize before attempting to inline, which should lead to a more accurate cost model and prevents the need for users to schedule additional duplicate cleanup passes before/after the inliner that would already be run during inlining.

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

show more ...

Use an Identifier instead of an OperationName internally for OpPassManager identification (NFC)

This allows to defers the check for traits to the execution instead of forcing it on the pipeline crea

Use an Identifier instead of an OperationName internally for OpPassManager identification (NFC)

This allows to defers the check for traits to the execution instead of forcing it on the pipeline creation.
In particular, this is making our pipeline creation tolerant to dialects not being loaded in the context yet.

Reviewed By: rriddle, GMNGeoffrey

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

show more ...

[mlir][Pass][NFC] Merge OpToOpPassAdaptor and OpToOpPassAdaptorParallel

This moves the threading check to runOnOperation. This produces a much cleaner interface for the adaptor pass, and will allow

[mlir][Pass][NFC] Merge OpToOpPassAdaptor and OpToOpPassAdaptorParallel

This moves the threading check to runOnOperation. This produces a much cleaner interface for the adaptor pass, and will allow for the ability to enable/disable threading in a much cleaner way in the future.

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

show more ...

Make MLIR Pass Timing output configurable through injection

This makes it possible for the client to control where the pass timings will
be printed.

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

Make MLIR Pass Timing output configurable through injection

This makes it possible for the client to control where the pass timings will
be printed.

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

show more ...

[mlir][NFC] Refactor ClassID into a TypeID class.

Summary: ClassID is a bit janky right now as it involves passing a magic pointer around. This revision hides the internal implementation mechanism w

[mlir][NFC] Refactor ClassID into a TypeID class.

Summary: ClassID is a bit janky right now as it involves passing a magic pointer around. This revision hides the internal implementation mechanism within a new class TypeID. This class is a value-typed wrapper around the original ClassID implementation.

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

show more ...

[mlir] NFC: Fix trivial typo

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

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

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

minor spelling tweaks

Closes tensorflow/mlir#290

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
Pip

minor spelling tweaks

Closes tensorflow/mlir#290

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
PiperOrigin-RevId: 284169681

show more ...

Add support for instance specific pass statistics.

Statistics are a way to keep track of what the compiler is doing and how effective various optimizations are. It is useful to see what optimization

Add support for instance specific pass statistics.

Statistics are a way to keep track of what the compiler is doing and how effective various optimizations are. It is useful to see what optimizations are contributing to making a particular program run faster. Pass-instance specific statistics take this even further as you can see the effect of placing a particular pass at specific places within the pass pipeline, e.g. they could help answer questions like "what happens if I run CSE again here".

Statistics can be added to a pass by simply adding members of type 'Pass::Statistics'. This class takes as a constructor arguments: the parent pass pointer, a name, and a description. Statistics can be dumped by the pass manager in a similar manner to how pass timing information is dumped, i.e. via PassManager::enableStatistics programmatically; or -pass-statistics and -pass-statistics-display via the command line pass manager options.

Below is an example:

struct MyPass : public OperationPass<MyPass> {
Statistic testStat{this, "testStat", "A test statistic"};

void runOnOperation() {
...
++testStat;
...
}
};

$ mlir-opt -pass-pipeline='func(my-pass,my-pass)' foo.mlir -pass-statistics

Pipeline Display:
===-------------------------------------------------------------------------===
... Pass statistics report ...
===-------------------------------------------------------------------------===
'func' Pipeline
MyPass
(S) 15 testStat - A test statistic
MyPass
(S) 6 testStat - A test statistic

List Display:
===-------------------------------------------------------------------------===
... Pass statistics report ...
===-------------------------------------------------------------------------===
MyPass
(S) 21 testStat - A test statistic

PiperOrigin-RevId: 284022014

show more ...

Fix minor spelling tweaks (NFC)

Closes tensorflow/mlir#177

PiperOrigin-RevId: 275692653

Pass the pointer of the parent pipeline collection pass to PassInstrumentation::run*Pipeline.

For the cases where there are multiple levels of nested pass managers, the parent thread ID is not enoug

Pass the pointer of the parent pipeline collection pass to PassInstrumentation::run*Pipeline.

For the cases where there are multiple levels of nested pass managers, the parent thread ID is not enough to distinguish the parent of a given pass pipeline. Passing in the parent pass gives an exact anchor point.

PiperOrigin-RevId: 272105461

show more ...

Fix a number of Clang-Tidy warnings.

PiperOrigin-RevId: 270632324

NFC: Pass PassInstrumentations by unique_ptr instead of raw pointer.

This makes the ownership model explicit, and removes potential user errors.

PiperOrigin-RevId: 269122834

Add support for coalescing adjacent nested pass pipelines.

This allows for parallelizing across pipelines of multiple operation types. AdaptorPasses can now hold pass managers for multiple operation

Add support for coalescing adjacent nested pass pipelines.

This allows for parallelizing across pipelines of multiple operation types. AdaptorPasses can now hold pass managers for multiple operation types and will dispatch based upon the operation being operated on.

PiperOrigin-RevId: 268017344

show more ...

Refactor PassTiming to support nested pipelines.

This is done via a new set of instrumentation hooks runBeforePipeline/runAfterPipeline, that signal the lifetime of a pass pipeline on a specific ope

Refactor PassTiming to support nested pipelines.

This is done via a new set of instrumentation hooks runBeforePipeline/runAfterPipeline, that signal the lifetime of a pass pipeline on a specific operation type. These hooks also provide the parent thread of the pipeline, allowing for accurate merging of timers running on different threads.

PiperOrigin-RevId: 267909193

show more ...

Refactor the pass manager to support operations other than FuncOp/ModuleOp.

This change generalizes the structure of the pass manager to allow arbitrary nesting pass managers for other operations, a

Refactor the pass manager to support operations other than FuncOp/ModuleOp.

This change generalizes the structure of the pass manager to allow arbitrary nesting pass managers for other operations, at any level. The only user visible change to existing code is the fact that a PassManager must now provide an MLIRContext on construction. A new class `OpPassManager` has been added that represents a pass manager on a specific operation type. `PassManager` will remain the top-level entry point into the pipeline, with OpPassManagers being nested underneath. OpPassManagers will still be implicitly nested if the operation type on the pass differs from the pass manager. To explicitly build a pipeline, the 'nest' methods on OpPassManager may be used:

// Pass manager for the top-level module.
PassManager pm(ctx);

// Nest a pipeline operating on FuncOp.
OpPassManager &fpm = pm.nest<FuncOp>();
fpm.addPass(...);

// Nest a pipeline under the FuncOp pipeline that operates on spirv::ModuleOp
OpPassManager &spvModulePM = pm.nest<spirv::ModuleOp>();

// Nest a pipeline on FuncOps inside of the spirv::ModuleOp.
OpPassManager &spvFuncPM = spvModulePM.nest<FuncOp>();

To help accomplish this a new general OperationPass is added that operates on opaque Operations. This pass can be inserted in a pass manager of any type to operate on any operation opaquely. An example of this opaque OperationPass is a VerifierPass, that simply runs the verifier opaquely on the current operation.

/// Pass to verify an operation and signal failure if necessary.
class VerifierPass : public OperationPass<VerifierPass> {
void runOnOperation() override {
Operation *op = getOperation();
if (failed(verify(op)))
signalPassFailure();
markAllAnalysesPreserved();
}
};

PiperOrigin-RevId: 266840344

show more ...

NFC: Refactor the PassInstrumentation framework to operate on Operation instead of llvm::Any.

Now that functions and modules are operations, Operation makes more sense as the opaque object to refer

NFC: Refactor the PassInstrumentation framework to operate on Operation instead of llvm::Any.

Now that functions and modules are operations, Operation makes more sense as the opaque object to refer to both.

PiperOrigin-RevId: 263883913

show more ...

Replace dyn_cast<> with isa<> when the returned value is unused (NFC)

Fix a gcc warning.

--

PiperOrigin-RevId: 247669360

Update variable in PassTiming to refer to system_clock instead of high_resolution_clock.

--

PiperOrigin-RevId: 241260071