MSVC fails to parse this construct, leading to
MlirTranslateMain.cpp(70): error C2065: 'inputSplitMarker': undeclared identifier
Just switching to brace init works around the issue
This allows to define custom splitters, which is interesting for
non-MLIR inputs and outputs to `mlir-translate`. For example, one may
use `; -----` as a splitter of `.ll` files. The splitters are now passed
as arguments into `splitAndProcessBuffer`, the input splitter defaulting
to the previous default (`// -----`) and the output splitter defaulting
to the empty string, which also corresponds to the previous default. The
behavior of the input split marker should not change at all; however,
outputs now have one new line *more* than before if there is no splitter
(old: `insertMarkerInOutput = false`, new: `outputSplitMarker = ""`) and
one new line *less* if there is one. The value of the input splitter is
exposed as a command line options of `mlir-translate` and other tools as
an optional value to the previously existing flag `-split-input-file`,
which defaults to the default splitter if not specified; the value of
the output splitter is exposed with the new `-output-split-marker`,
which default to the empty string in `mlir-translate` and the default
splitter in the other tools. In short, the previous usage or omission of
the flags should result in previous behavior (modulo the new lines
mentioned before).
The patch enables roundtrip to textual file when running
`--verifyRoundtrip`. The verification is successful if both textual and
bytecode formats can roundtrip successfully.
This PR adds API `makeReproducer` and cl::opt flag
`--mlir-generate-reproducer=<filename>` in order to allow for mlir
reproducer dumps even when the pipeline doesn't crash.
This PR also decouples the code that handles generation of an MLIR
reproducer from the crash recovery portion. The purpose is to allow for
generating reproducers outside of the context of a compiler crash.
This will be useful for frameworks and runtimes that use MLIR where it
is needed to reproduce the pipeline behavior for reasons outside of
diagnosing crashes. An example is for diagnosing performance issues
using offline tools, where being able to dump the reproducer from a
runtime compiler would be helpful.
When serializing to bytecode, users can select the option to elide
resources from the bytecode file. This will instruct the bytecode writer
to serialize only the key and resource kind, while skipping
serialization of the data buffer. At parsing, the IR is built in memory
with valid (but empty) resource handlers.
Seprate registeration and CLI parsing from `MlirOptMain` to
`mlir::registrationAndParseCLIOptions` and a new `MlirOptMain` so that
external tools to drive `mlir-opt` can call these two new APIs to get CLI
option values before running `MlirOptMain`.
Running:
MLIR_OPT_CHECK_IR_ROUNDTRIP=1 ninja check-mlir
will now exercises all of our test with a round-trip to bytecode and a comparison for equality.
Reviewed By: rriddle, ftynse, jpienaar
Differential Revision: https://reviews.llvm.org/D90088
When tooling out there produces a reproducer that is archived, the first thing
a user is likely to expect is to process this as they do with any MLIR file.
However https://reviews.llvm.org/D126447 changed the behavior of mlir-opt to
eliminate the `--run-reproducer` option and instead automatically run it when
present in the input file. This creates a discrepancy in how mlir-opt behaves
when fed with an input file, and is surprising for users.
The explicit passing of `--run-reproducer` to express user-intent seems more
in line with what is expected from `mlir-opt`.
Reviewed By: rriddle, jpienaar
Differential Revision: https://reviews.llvm.org/D149820
Can't return a well-formed IR output while enabling version to be bumped
up during emission. Previously it would return min version but
potentially invalid IR which was confusing, instead make it return
error and abort immediately instead.
Differential Revision: https://reviews.llvm.org/D149569
Add method to set a desired bytecode file format to generate. Change
write method to be able to return status including the minimum bytecode
version needed by reader. This enables generating an older version of
the bytecode (not dialect ops, attributes or types). But this does not
guarantee that an older version can always be generated, e.g., if a
dialect uses a new encoding only available at later bytecode version.
This clamps setting to at most current version.
Differential Revision: https://reviews.llvm.org/D146555
This includes a small runtime acting as callback for the ExecutionEngine
and a C API that makes it possible to control from the debugger.
A python script for LLDB is included that hook a new `mlir` subcommand
and allows to set breakpoints and inspect the current action, the context
and the stack.
Differential Revision: https://reviews.llvm.org/D144817
This patch add support for loading IRDL dialects at runtime
with `mlir-opt`.
Given the following `dialect.irdl` file:
```mlir
module {
irdl.dialect @cmath {
irdl.type @complex {
%0 = irdl.is f32
%1 = irdl.is f64
%2 = irdl.any_of(%0, %1)
irdl.parameters(%2)
}
irdl.operation @norm {
%0 = irdl.any
%1 = irdl.parametric @complex<%0>
irdl.operands(%1)
irdl.results(%0)
}
}
```
the IRDL file can be loaded with the `mlir-opt --irdl-file=dialect.irdl`
command, and the following file can then be parsed:
```mlir
func.func @conorm(%p: !cmath.complex<f32>, %q: !cmath.complex<f32>) -> f32 {
%norm_p = "cmath.norm"(%p) : (!cmath.complex<f32>) -> f32
%norm_q = "cmath.norm"(%q) : (!cmath.complex<f32>) -> f32
%pq = arith.mulf %norm_p, %norm_q : f32
return %pq : f32
}
```
To minimize the size of this patch, the operation, attribute, and type verifier are all always returning `success()`.
Depends on D144692
Reviewed By: rriddle, Mogball, mehdi_amini
Differential Revision: https://reviews.llvm.org/D144693
This will match the locations attached to the IRunits passed in as context
with an action.
This is a recommit of d09c80515d after fixing the test on Windows.
Differential Revision: https://reviews.llvm.org/D144815
This patch add support for loading IRDL dialects at runtime
with `mlir-opt`.
Given the following `dialect.irdl` file:
```mlir
module {
irdl.dialect @cmath {
irdl.type @complex {
%0 = irdl.is f32
%1 = irdl.is f64
%2 = irdl.any_of(%0, %1)
irdl.parameters(%2)
}
irdl.operation @norm {
%0 = irdl.any
%1 = irdl.parametric @complex<%0>
irdl.operands(%1)
irdl.results(%0)
}
}
```
the IRDL file can be loaded with the `mlir-opt --irdl-file=dialect.irdl`
command, and the following file can then be parsed:
```mlir
func.func @conorm(%p: !cmath.complex<f32>, %q: !cmath.complex<f32>) -> f32 {
%norm_p = "cmath.norm"(%p) : (!cmath.complex<f32>) -> f32
%norm_q = "cmath.norm"(%q) : (!cmath.complex<f32>) -> f32
%pq = arith.mulf %norm_p, %norm_q : f32
return %pq : f32
}
```
To minimize the size of this patch, the operation, attribute, and type verifier are all always returning `success()`.
Depends on D144692
Reviewed By: rriddle, Mogball, mehdi_amini
Differential Revision: https://reviews.llvm.org/D144693
Implementation of Pass and Dialect Plugins that mirrors LLVM Pass Plugin
implementation from the new pass manager.
Currently the implementation only supports using the pass-pipeline option
for adding passes. This restriction is imposed by the `PassPipelineCLParser`
variable in mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:114 that loads the
parse options statically before parsing the cmd line args.
```
mlir-opt stanalone-plugin.mlir --load-dialect-plugin=lib/libStandalonePlugin.so --pass-pipeline="builtin.module(standalone-switch-bar-foo)"
```
Reviewed By: rriddle, mehdi_amini
Differential Revision: https://reviews.llvm.org/D147053
Implementation of Pass and Dialect Plugins that mirrors LLVM Pass Plugin implementation from the new pass manager.
Currently the implementation only supports using the pass-pipeline option for adding passes. This restriction is imposed by the `PassPipelineCLParser` variable in mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:114 that loads the parse options statically before parsing the cmd line args.
```
mlir-opt stanalone-plugin.mlir --load-dialect-plugin=lib/libStandalonePlugin.so --pass-pipeline="builtin.module(standalone-switch-bar-foo)"
```
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D147053
Implementation of Pass and Dialect Plugins that mirrors LLVM Pass Plugin implementation from the new pass manager.
Currently the implementation only supports using the pass-pipeline option for adding passes. This restriction is imposed by the `PassPipelineCLParser` variable in mlir/lib/Tools/mlir-opt/MlirOptMain.cpp:114 that loads the parse options statically before parsing the cmd line args.
```
mlir-opt stanalone-plugin.mlir --load-dialect-plugin=lib/libStandalonePlugin.so --pass-pipeline="builtin.module(standalone-switch-bar-foo)"
```
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D147053
-mlir-print-ir-module-scope option cannot be used without disabling multithread for pass manager. For the usability, we can throw a validation error in mlir-opt instead of assertion failure.
Issue: https://github.com/llvm/llvm-project/issues/61578
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D146785
Integrate the `tracing::ExecutionContext()` into mlir-opt with a new
--log-action-to=<file> option to demonstrate the feature.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D144813
It happens from time to time that one may run mlir-opt expecting something to
happen, but the process is waiting on stdin. Print a message when reading from
stdin to warn developers.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D145469
The concept of the ActionManager acts as a sort of "Hub" that can receive
various types of action and dispatch them to a set of registered handlers.
One handler will handle the action or it'll cascade to other handlers.
This model does not really fit the current evolution of the Action tracing
and debugging: we can't foresee a good case where this behavior compose with
the use-case behind the handlers. Instead we simplify it with a single
callback installed on the Context.
Differential Revision: https://reviews.llvm.org/D144811
This is a preparation for adding support for more infrastructure around the concept
of Action and make tracing Action more of a first class concept.
The doc will be updated later in a subsequent revision after the changes are
completed.
Action belongs to IR because of circular dependency: Actions are dispatched through
the MLIRContext but Action will learn to encapsulate IR construct.
Differential Revision: https://reviews.llvm.org/D144809
This allows for downstream *-opt tools to stay always aligned with the options
exposed by mlir-opt.
It aligns the "generic" options with the more "components" ones like the
pass manager options or the context options.
Differential Revision: https://reviews.llvm.org/D144782
Currently `PassManager` defaults to being anchored on `builtin.module`.
Switching the default makes `PassManager` consistent with
`OpPassManager` and avoids the implicit dependency on `builtin.module`.
Specifying the anchor op type isn't strictly necessary when using
explicit nesting (existing pipelines will continue to work), but I've
updated most call sites to specify the anchor since it allows for better
error-checking during pipeline construction.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D137731
The bytecode reader currently has no mechanism that allows for directly referencing
data from the input buffer safely. This commit adds shared_ptr<SourceMgr> overloads
that provide an explicit and safe way of extending the lifetime of the input. The usage of
these new overloads is adopted in all of our tooling, and is implicitly used in the filename
only parser methods.
Differential Revision: https://reviews.llvm.org/D139366
The pipeline strings have been getting more verbose over time, adding an
alias for the option should help improve the ergonomics a bit.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D137347
Add an option to dump the pipeline that will be run to stderr. A
dedicated option is needed since the existing `test-dump-pipeline`
pipeline won't be usable with `-pass-pipeline` after D135745.
Reviewed By: rriddle, mehdi_amini
Differential Revision: https://reviews.llvm.org/D135747
This is very useful when you want to parse IR even if
its invalid (e.g. bytecode). It's also useful if you don't
want to pay the cost of verification in certain situations.
Differential Revision: https://reviews.llvm.org/D134847
This adds a `--no-implicit-module` option, which disables the insertion
of a top-level `builtin.module` during parsing. In this mode any op may
be top-level, however it's required that there be exactly one top-level
op in the source.
`parseSource{File,String}` now support `Operation *` as the container op
type, which disables the top-level-op-insertion behaviour.
Following patches will add the same option to the other tools as well.
Depends on D133644
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D133645
Currently the pass manager is created before parsing, which requires an
assumption that the top-level operation will be `builtin.module`.
Delaying the creation allows for using the parsed top-level operation as
the PassManager operation instead.
A followup change will allow for parsing top-level operations other than
`builtin.module`.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D133644
This is necessary/useful for building generic tooling that can roundtrip external
resources without needing to explicitly handle them. For example, this allows
for viewing the resources encoded within a bytecode file without having to
explicitly know how to process them (e.g. making it easier to interact with a
reproducer encoded in bytecode).
Differential Revision: https://reviews.llvm.org/D133460
This commit adds a new bytecode serialization format for MLIR.
The actual serialization of MLIR to binary is relatively straightforward,
given the very very general structure of MLIR. The underlying basis for
this format is a variable-length encoding for integers, which gets heavily
used for nearly all aspects of the encoding (given that most of the encoding
is just indexing into lists).
The format currently does not provide support for custom attribute/type
serialization, and thus always uses an assembly format fallback. It also
doesn't provide support for resources. These will be added in followups,
the intention for this patch is to provide something that supports the
basic cases, and can be built on top of.
https://discourse.llvm.org/t/rfc-a-binary-serialization-format-for-mlir/63518
Differential Revision: https://reviews.llvm.org/D131747
