Anastasia added a comment. In D127579#3585537 <https://reviews.llvm.org/D127579#3585537>, @nikic wrote:
> In D127579#3585516 <https://reviews.llvm.org/D127579#3585516>, @beanz wrote: > >> @nikic the most important thing you need to know about SPIR-V is that it is >> a virtual ISA based on LLVM IR. The ISA itself encodes types for pointers >> just like LLVM IR would. > > Okay ... I guess my next question would be how the SPIR-V situation differs > from the DXIL situation. For DXIL you have already implemented code to > "guess" pointer types insofar as they are relevant -- does SPIR-V need > something more than that? > > Clang is only permitted to encode pointer type information if that pointer > type has some kind of direct semantic meaning -- say, if the pointer element > type affects the call ABI in some way. If it does not have direct semantic > meaning, then deriving the pointer type based on usage (as DXIL does) and > using that for emission would be right approach. I guess the problem might be that we can't always derive the type, for example if we have a translation unit: extern void foo(int * ptr); kernel void k(int * ptr) { foo(ptr); } then if in another translation module you have something like: void foo(int * ptr){ *ptr = 1; } For this program `foo` will translate into SPIR-V with different function prototype because in the first unit the type can't be deduced or deduced to some default type but in the second case it is deduced to the exact type. So the functions in two modules will have two different prototypes when mapped into SPIR-V and therefore linking won't be resolved?.. while in OpenCL sources it is just the same function `foo`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D127579/new/ https://reviews.llvm.org/D127579 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
