[PATCH] D127579: [clang][WIP] add option to keep types of ptr args for non-kernel functions in metadata

Tue Jun 21 02:15:45 PDT 2022

nikic added a comment.

In D127579#3598306 <https://reviews.llvm.org/D127579#3598306>, @Anastasia wrote:

> 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?

The bitcasts would be in the definition only, when the pointer arguments actually get used in a typed manner. The prototype would always include `i8*` arguments only.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127579/new/

https://reviews.llvm.org/D127579