[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