The cuda-runner registers two pass pipelines for nested passes,
so that we don't have to use verbose textual pass pipeline specification.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
750 ms | x64 windows > MLIR.Examples/Toy/Ch6::jit.toy | |
4,620 ms | x64 windows > MLIR.Examples/Toy/Ch7::jit.toy |
Event Timeline
mlir/tools/mlir-cuda-runner/mlir-cuda-runner.cpp | ||
---|---|---|
175 | I'm not fond of exposing arbitrary pipeline to the runner, can we leave this to mlir-opt and pipe it to the runner instead? There is value in keeping the tools focused in the Unix-style, without loss of generality I think. |
mlir/tools/mlir-cuda-runner/mlir-cuda-runner.cpp | ||
---|---|---|
175 | I see your point, and this was intended as a step in that direction, at least allowing textual pass pipeline specification on the command line instead of hardcoding it in the cuda-runner.
We will presumably need a cuda-opt though which runs or provides the gpu-to-cubin pipeline added here, because mlir-opt would not want to depend on CUDA. I will make the above two changes here and leave the cuda-opt > mlir-opt > cpu-runner piping as a follow-up. As a side note, the downside of tests piping code through tools is that it's harder to setup IDEs for debugging. When I debug an mlir-opt > cpu-runner test, I think twice before setting up proper debugging, add some printfs, waste time, and then do it anyway ;-) |
I'm not fond of exposing arbitrary pipeline to the runner, can we leave this to mlir-opt and pipe it to the runner instead? There is value in keeping the tools focused in the Unix-style, without loss of generality I think.