Anastasia added a comment. In D127579#3595461 <https://reviews.llvm.org/D127579#3595461>, @nikic wrote:
> In D127579#3588626 <https://reviews.llvm.org/D127579#3588626>, @Anastasia > wrote: > >> In D127579#3586092 <https://reviews.llvm.org/D127579#3586092>, @nikic wrote: >> >>> @Anastasia Thanks, that does sound like a legitimate reason to include the >>> information. I want to double check though, does linking the modules >>> actually fail if the functions have signatures that differ only by pointer >>> types? At least for normal LLVM IR this would work fine, and would just >>> result in the insertion of a bitcast during linking (and then typically the >>> bitcast would get shifted from the called function to the call arguments >>> later). >> >> @nikic If I use `spirv-link` with two modules that have mismatching pointee >> type in a function parameter I get an error: >> >> error: 0: Type mismatch on symbol "foo" between imported variable/function >> %6 and exported variable/function %17. >> >> The way I understand a bitcast instruction in SPIR-V (`OpBitcast` in >> https://www.khronos.org/registry/SPIR-V/specs/unified1/SPIRV.html#_conversion_instructions) >> is that it can only apply to pointer types which are distinct from function >> types. Note that I believe that function pointers are illegal, at least we >> disallow them in OpenCL. > > Okay ... can we maybe turn this around then? Always emit function parameters > as `i8*` and bitcast them as needed, even if it is possible to guess a better > type based on the definition? (Let's ignore the image type case here, which > seems to have different requirements from the rest.) So where would bitcasts be emitted to reconstruct the function prototypes correctly? 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
