[Mlir-commits] [mlir] [mlir] Add `MLIR_USE_FALLBACK_TYPE_IDS` macro support for `TypeID` (PR #126999)
Stef Lindall
llvmlistbot at llvm.org
Sun Feb 16 09:02:53 PST 2025
bethebunny wrote:
Thank you so much for the feedback!
- My project uses Bazel, I'm much less familiar with CMake, but I'll look into how those are defined and send a followup PR.
- Where do you think is the right place to add more documentation? I learned mainly through the docs in `TypeID.h` so I added some threads there, but I definitely admit that it would be quite hard for someone to meaningfully follow this path themselves still.
- I can confirm that this completely resolves the issue in my specific case.
- Consider a tree of SOs using a tree of MLIR dialects
- The property we want to achieve is that for library A and B, regardless of where they exist in this tree, if they both use a shared MLIR type T, then `TypeID::get<T_A>() == TypeID::get<T_B>()`.
- Note that this is not true when A and B separately compile definitions of `T` with explicit type IDs. In this case each type ID is the memory location of separate global statics.
- In practice this has proven intractable to achieve when there's a large tree of SOs using many different dialects, and in particular with `visibility=hidden`. For each dialect you need to designate an SO which owns this dialect's types, and ensure that no downstream SO decides that it should re-define them.
- With fallback type IDs you have the same problem, but only 1 occurrence of it: you need all libraries to agree on a single definition of `registerImplicitTypeID`.
- This is relatively practical to achieve since each library needs to depend on `mlir:IR` anyway.
- In this case, when `T_A` and `T_B` are defined, each are assigned static TypeIDs by calling `registerImplicitTypeID`, which internally recognizes that `T_A` and `T_B` are the same type.
- Now `TypeID::get<T_A>() == TypeID::get<T_B>()` because they were both assigned the same type ID by the central registry.
https://github.com/llvm/llvm-project/pull/126999
More information about the Mlir-commits
mailing list