Deprecations & Current Refactoring
This page collects current deprecations in MLIR of API and features we intend to remove soon, as well as large refactoring an migration on-going. We try to list these here for the purpose of helping downstream users keeping up with MLIR development.
Deprecated
Use the free function variants for dyn_cast
/cast
/isa
/…
When casting attributes or type, use the free functions variants, e.g.,
dyn_cast<T>(x)
, isa<T>(x)
, etc. Use of the cast methods variants (e.g.,
x.dyn_cast<T>()
) should be avoided in new code as we’ll remove these
methods in the future.
Discussion on Discourse
On-going Refactoring & large changes
Past Deprecation and Refactoring
LLVM 17
“Promised Interface” and the need to explicitly register InlinerExtension for the FuncDialect
.
We’re tightening the contract around injecting interfaces into the system externally, starting with
DialectInterface
. As an important visible change at the moment is that if you’re using the inliner
with the FuncDialect
, you need to call func::registerAllExtensions(registry);
when setting up
your MLIRContext
.
Properties && changes to the generic printing format
See on Discourse.
Properties is a new feature in MLIR that will allow to separate the storage of
inherent attributes from the discardable ones. One key visible change is the
generic assembly format which gain a new attribute entry in-between <
>
.
preloadDialectInContext
has been deprecated for >1y and was removed
See https://github.com/llvm/llvm-project/commit/9c8db444bc85
If you have an mlir-opt tool and you’re still depending on
preloadDialectInContext
, you need to revisit your pipeline. This option
used with mlir-opt is hiding issues with the pipeline, and indications of
missing getDependentDialects().
Discussion on Discourse
Migrating mlir-opt
-like tools to use MlirOptMainConfig
See https://github.com/llvm/llvm-project/commit/ffd6f6b91a3
If your mlir-opt
-like tool is using the
MlirOptMain(int argc, char **argv, ...)
entry point you won’t be affected,
otherwise, see the
Discussion on Discourse
Deprecation of gpu-to-(cubin|hsaco)
in favor of GPU compilation attributes
GPU compilation attributes are a completely new mechanism for handling the compilation of GPU modules down to binary or other formats in an extensible way. This mechanism lifts many current restrictions the GPU serialization passes had, like being present only if the CUDA driver is there or not linking to LibDevice.
One key difference is the usage of ptxas
or the nvptxcompiler
library for compiling PTX
to binary; hence the CUDATollkit is required for generating binaries.
For these attributes to work correctly, making registration calls to registerNVVMTargetInterfaceExternalModels
,
registerROCDLTargetInterfaceExternalModels
and registerOffloadingLLVMTranslationInterfaceExternalModels
are necessary.
The passes gpu-to-(cubin|hsaco)
will be removed in a future release.
LLVM 18
Port uses of LLVM Dialect to opaque pointers
LLVM 17 has stopped officially supporting typed pointers, and MLIRs LLVM Dialect is now in the process of dropping the support as well. This was announced back in February 2023 ( PSA) , and now the final steps, i.e., removing the typed pointers, have started ( PSA). If you are still targeting LLVM dialect with typed pointers, an update to support opaque pointers will be necessary.
LLVM 19
Removal of gpu-to-(cubin|hsaco)
in favor of GPU compilation attributes
Notice: The passes gpu-to-(cubin|hsaco)
have been removed from the monorepo, use target attributes instead. See the LLVM 17 section on this page for more information.