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

Reply via email to