aaronmondal added a comment. Well, I can already feel the pain that distro maintainers having to build the next ROCm releases 😅
I wonder what the better course of action is here: 1. Port this patch to Clang 16 so that users with new hardware will be able to build ROCm 5.5, but make it impossible to build ROCm 5.4 and older with clang 16. 2. Don't port this patch and have a ~6 months gap during which users with the 7900 GPUs won't be able to build ROCm with a stable Clang version, requiring distro maintainers to use several toolchains and source-based distro users to use differentl compatibility patches for different ROCm releases. So basically when 8900 GPUs are announced, clang would support ROCm for 7900 GPUs 😅 Would there be a way to retain at least *some* backwards compatibility or version interoperability? For instance, via an `#ifdef CLANG_VERSION_MAJOR` in the device libs and an `#ifdef INCOMPATIBLE_AMDGPU_INSTS` in Clang? This would obviously very ugly, but it still seems better to me than locking out users (and more likely, ROCm contributors) from using 7900 GPUs if they are unable to build Clang themselves. Users already complain about how hard it is to build ROCm, and they also complain about the frequent breaking changes Clang. I'm very much in favor of moving fast, but I'm worried that complete disregard for backwards compatibility like this with no clear upgrade path or fallback mechanism could cause a lot of frustration for users and distro maintainers. Maybe there is some other, prettier way to solve this? 🥹 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142507/new/ https://reviews.llvm.org/D142507 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
