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
We currently generate reproducer configurations using a comment placed at
the top of the generated .mlir file. This is kind of hacky given that comments
have no semantic context in the source file and can easily be dropped. This
strategy also wouldn't work if/when we have a bitcode format. This commit
switches to using an external assembly resource, which is verifiable/can
work with a hypothetical bitcode naturally/and removes the awkward processing
from mlir-opt for splicing comments and re-applying command line options. With
the removal of command line munging, this opens up new possibilities for
executing reproducers in memory.
Differential Revision: https://reviews.llvm.org/D126447
`enableSplitting` simply enables/disables whether we should split
or use the full buffer. `insertMarkerInOutput` toggles if split markers
should be inserted in between prcessed output chunks.
These options allow for merging the duplicate code paths we have
when splitting is optional.
Differential Revision: https://reviews.llvm.org/D128764
MlirOptMain is currently awkwardly shoved into mlir/Support. This commit
moves it to the Tools/ directory, which is intended for libraries used to
implement tools.
Differential Revision: https://reviews.llvm.org/D121025
