nikic added a comment. 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.) 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
