d7eba20052
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
29 lines
1.2 KiB
MLIR
29 lines
1.2 KiB
MLIR
// RUN: mlir-opt %s -pass-pipeline='module(test-dynamic-pipeline{op-name=inner_mod1 dynamic-pipeline=cse})' --mlir-disable-threading -print-ir-before-all 2>&1 | FileCheck %s --check-prefix=NOTNESTED --check-prefix=CHECK
|
|
// RUN: mlir-opt %s -pass-pipeline='module(test-dynamic-pipeline{op-name=inner_mod1 run-on-nested-operations=1 dynamic-pipeline=cse})' --mlir-disable-threading -print-ir-before-all 2>&1 | FileCheck %s --check-prefix=NESTED --check-prefix=CHECK
|
|
|
|
|
|
// Verify that we can schedule a dynamic pipeline on a nested operation
|
|
|
|
func @f() {
|
|
return
|
|
}
|
|
|
|
// CHECK: IR Dump Before
|
|
// CHECK-SAME: TestDynamicPipelinePass
|
|
// CHECK-NEXT: module @inner_mod1
|
|
module @inner_mod1 {
|
|
// We use the print-ir-after-all dumps to check the granularity of the
|
|
// scheduling: if we are nesting we expect to see to individual "Dump Before
|
|
// CSE" output: one for each of the function. If we don't nest, then we expect
|
|
// the CSE pass to run on the `inner_mod1` module directly.
|
|
|
|
// CHECK: Dump Before CSE
|
|
// NOTNESTED-NEXT: @inner_mod1
|
|
// NESTED-NEXT: @foo
|
|
module @foo {}
|
|
// Only in the nested case we have a second run of the pass here.
|
|
// NESTED: Dump Before CSE
|
|
// NESTED-NEXT: @baz
|
|
module @baz {}
|
|
}
|