rampitec added a comment. In D142507#4127275 <https://reviews.llvm.org/D142507#4127275>, @aaronmondal wrote:
>> I cannot say there was much choice. The only real choice was to postpone the >> split and magnify the problem in the future. As for the ifdefs, this might >> be possible in the device-libs but I do not see how to do it the >> Builtins.def. > > Hmm maybe ifdefs in the device libs would also just delay the issue. Maybe it > really is best to pull this change into Clang 16 and accept the fact that > it's an unfortunate situation, but at least give users with very recent > hardware the option to use a regular Clang to build ROCm. Realistically, > those actually upgrading to Clang 16 early will also be those upgrading to > ROCm5.5 early and likely also be those most likely to have 7900 GPUs. > > Somehow, telling users "if you have a new GPU you need new Clang + ROCm" and > "if you want new ROCm for your old GPU you need to also upgrade Clang" sounds > better to me than telling them "if you have a new GPU you are SOL unless you > use binary releases or build the amd-llvm-fork" 😅 In fact pulling it into clang-16 does not automatically mean it should be the same in the rocm clang build... So this may be a way to go. @b-sumner do you have any objections to backport this into clang-16? @aaronmondal what exactly backport will look like? 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
