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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to