Maintaining LLVM API compatibility with macro guards instead of hash

[quic-sanirudh]

Hi,

I work at Qualcomm and we're using triton to target Hexagon architecture. I'm new to triton community, so I'm not really sure whether this is the right place to post this, so please advice if there's a better place to ask this.

We are facing issues with maintaining Triton with downstream LLVM because Triton works with a specific LLVM hash and hence, local changes to LLVM/MLIR downstream has to first be upstreamed and the llvm hash has to be updated in triton to support a newer commit.

I wanted to understand if the community would be interested in a slightly different way of maintaining compatibility by supporting all versions of LLVM at the same time using cpp macro (#ifdef/#if) guards on LLVM versions instead of updating the code to always match a specific hash. This approach is used in the TVM compiler. The code here is an example of how this is handled.

The high-level idea is to introduce a CMake level macro definition for LLVM_VERSION, that could then be used in the code using macro guards to support multiple versions of LLVM/MLIR APIs. This would remove the dependency on maintaining a single LLVM hash and would (over time) just support all versions of LLVM repo

Please let me know your thoughts.

Thanks,
Anirudh

[ThomasRaoux]

supporting multiple LLVM version is usually done by projects that upgrade based on LLVM releases. We upgrade LLVM much more often as we often need features or bug fixes from MLIR or LLVM. I'm not aware of any project that can support any LLVM hash, I doubt this is possible.
Also as our code is MLIR based the surface area between LLVM repo and triton is very large which would also make this impractical.
We tend to always be very close to top of tree so if you have a backend that stays in sync with top of tree most of the time it should be compatible with Triton even if in sync with a slightly different commit.

[quic-sanirudh]

Thanks for the reply @ThomasRaoux.