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

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D127579#3598308 <https://reviews.llvm.org/D127579#3598308>, @nikic wrote:

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

Ok, so does it mean that all pointer parameters in function definitions compiled for SPIR-V targets in clang would just be cast to the typed pointer? Then we only have untyped pointers in the declarations of functions? Perhaps I am missing something but would it not just be easier to keep the pointer types completely as it used to be, since it is going to be present nearly everywhere apart from declarations?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579