| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
This change refactors pass options to be more similar to how statistics are modeled. More specifically, the options are specified directly on the pass instead of in a separate options class. (Note that the behavior and specification for pass pipelines remains the same.) This brings about several benefits:
* The specification of options is much simpler
* The round-trip format of a pass can be generated automatically
* This gives a somewhat deeper integration with "configuring" a pass, which we could potentially expose to users in the future.
PiperOrigin-RevId: 286953824
|
| |
|
|
| |
PiperOrigin-RevId: 286906740
|
| |
|
|
|
|
|
|
| |
in `mlir` namespace.
Aside from being cleaner, this also makes the codebase more consistent.
PiperOrigin-RevId: 286206974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows individual passes to define options structs and for these options to be parsed per instance of the pass while building the pass pipeline from the command line provided textual specification.
The user can specify these per-instance pipeline options like so:
```
struct MyPassOptions : public PassOptions<MyPassOptions> {
Option<int> exampleOption{*this, "flag-name", llvm::cl::desc("...")};
List<int> exampleListOption{*this, "list-flag-name", llvm::cl::desc("...")};
};
static PassRegistration<MyPass, MyPassOptions> pass("my-pass", "description");
```
PiperOrigin-RevId: 273650140
|
| |
|
|
| |
PiperOrigin-RevId: 270704572
|
| |
|
|
|
|
| |
This allows for users other than those on the command line to apply a textual description of a pipeline to a given pass manager.
PiperOrigin-RevId: 269017028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
strings.
This allows for explicitly specifying the pipeline to add to the pass manager. This includes the nesting structure, as well as the passes/pipelines to run. A textual pipeline string is defined as a series of names, each of which may in itself recursively contain a nested pipeline description. A name is either the name of a registered pass, or pass pipeline, (e.g. "cse") or the name of an operation type (e.g. "func").
For example, the following pipeline:
$ mlir-opt foo.mlir -cse -canonicalize -lower-to-llvm
Could now be specified as:
$ mlir-opt foo.mlir -pass-pipeline='func(cse, canonicalize), lower-to-llvm'
This will allow for running pipelines on nested operations, like say spirv modules. This does not remove any of the current functionality, and in fact can be used in unison. The new option is available via 'pass-pipeline'.
PiperOrigin-RevId: 268954279
|
| |
|
|
|
|
|
|
| |
Fix clang warning
--
PiperOrigin-RevId: 247558931
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass execution. This instrumentation can be added directly to the PassManager via 'enableIRPrinting'. mlir-opt exposes access to this instrumentation via the following flags:
* print-ir-before=(comma-separated-pass-list)
- Print the IR before each of the passes provided within the pass list.
* print-ir-before-all
- Print the IR before every pass in the pipeline.
* print-ir-after=(comma-separated-pass-list)
- Print the IR after each of the passes provided within the pass list.
* print-ir-after-all
- Print the IR after every pass in the pipeline.
* print-ir-module-scope
- Always print the Module IR, even for non module passes.
PiperOrigin-RevId: 238523649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by providing a static registration facility PassPipelineRegistration that works similarly to PassRegistration except for it also takes a function that will add necessary passes to a provided PassManager.
void pipelineBuilder(PassManager &pm) {
pm.addPass(new MyPass());
pm.addPass(new MyOtherPass());
}
static PassPipelineRegistration Unused("unused", "Unused pass", pipelineBuilder);
This is also useful for registering specializations of existing passes:
Pass *createFooPass10() { return new FooPass(10); }
static PassPipelineRegistration Unused("unused", "Unused pass", createFooPass10);
PiperOrigin-RevId: 235996282
|
| |
|
|
|
|
| |
used for the ID field to be self documenting. It also allows for the compiler to know the set alignment of the ID object, which is useful for storing pointer identifiers within llvm data structures.
PiperOrigin-RevId: 235107957
|
|
|
* PassRegistry is split into its own source file.
* Pass related files are moved to a new library 'Pass'.
PiperOrigin-RevId: 234705771
|
