Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Nice to see this in action! Right in time also for some parallel work in the sparse compiler!
mlir/integration_test/Dialect/Async/CPU/microbench-linalg-async-parallel-for.mlir | ||
---|---|---|
75 | Nit: if you pick another name like "SERIAL" for the sequential case, the output nicely lines up | |
mlir/lib/ExecutionEngine/AsyncRuntime.cpp | ||
234 | I am guessing it is okay that merely pulling in the async runtime lib also implies starting a threadpool? |
Are the changes in mlir/lib/Conversion/AsyncToLLVM/AsyncToLLVM.cpp bug fixes? Can you add IR tests for this (and commit separately so there is a proper commit description)?
mlir/integration_test/Dialect/Async/CPU/microbench-linalg-async-parallel-for.mlir | ||
---|---|---|
75 | Aren't they identical? Can't we just use "CHECK" and have one? | |
mlir/lib/ExecutionEngine/AsyncRuntime.cpp | ||
234 | I'd expect this to only start the thread pool if there is something to execute (when this function is invoked for the first time)? |
mlir/integration_test/Dialect/Async/CPU/microbench-linalg-async-parallel-for.mlir | ||
---|---|---|
75 | Interesting. I may have set the wrong example in other test cases, where I duplicate the CHECK-XXX even if the cases are identical to make it easier to see which of the XXX variants was responsible for a failure. But I guess you could indeed use one CHECK and just look at the command line of the failing report..... |
Will submit changes to AsyncToLLVM.cpp in a separate PR.
mlir/lib/ExecutionEngine/AsyncRuntime.cpp | ||
---|---|---|
234 | Yes, this will be instantiated only of thread pool is required for async execution. Also this runtime is primarily for testing, e.g. in TF it will be replaced with a TFRT integration. |
This seems to be failing on some configurations https://buildkite.com/mlir/mlir-core/builds/9510#4c77cda4-9dce-4b4d-8ad7-c220a892865b , known issue?
mlir/lib/ExecutionEngine/AsyncRuntime.cpp | ||
---|---|---|
234 | I believe that on the medium-to-long-term we will want a proper runtime here, in the scope of the low-level bits of TFRT. So I rather not consider this "just for testing" if it means that we're don't have a path to productionize this or if it becomes too hacky. This should all make sense and have an integration story other than TF/TFRT upstream. |
Nit: if you pick another name like "SERIAL" for the sequential case, the output nicely lines up