AlexVlx wrote: > Thanks @AlexVlx for this change. This should work fine for > SPIRV-LLVM-Translator (and SPIR-V backend). Adding @michalpaszkowski for > input from SPIR-V backend side. Recently, this restriction on LLVM IR input > to our translator was docuemnted: > https://github.com/KhronosGroup/SPIRV-LLVM-Translator/blob/main/docs/SPIRVRepresentationInLLVM.rst#global-variables > _"A global variable resides in an address space, and the default address > space in LLVM is zero. The SPIR-V storage class represented by the zero LLVM > IR address spaces is Function. However, SPIR-V global variable declarations > are OpVariable instructions whose Storage Class cannot be Function. This > means that global variable declarations must always have an address space > specified and that address space cannot be 0."_ So, your change will help to > make the LLVM IR more suitable for the translator. > > One quick pointer. I did notice a similar commit for the AMDGPU backend - > https://reviews.llvm.org/D84345 Here, there are some updates to the > llvm/lib/IR/AutoUpgrade.cpp. Do we need similar changes here? > > Thanks
Thanks for the feedback, and great call on the AutoUpgrade part, I had not considered that at all; I believe we can just re-use the AMDGPU approach, and just adapt the predicate, but I'll give it a think and then update this PR accordingly. https://github.com/llvm/llvm-project/pull/88455 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits