[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 cfe-commits at lists.llvm.org
Wed Jun 15 09:09:54 PDT 2022


Anastasia added a comment.

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

> In D127579#3585516 <https://reviews.llvm.org/D127579#3585516>, @beanz wrote:
>
>> @nikic the most important thing you need to know about SPIR-V is that it is a virtual ISA based on LLVM IR. The ISA itself encodes types for pointers just like LLVM IR would.
>
> Okay ... I guess my next question would be how the SPIR-V situation differs from the DXIL situation. For DXIL you have already implemented code to "guess" pointer types insofar as they are relevant -- does SPIR-V need something more than that?
>
> Clang is only permitted to encode pointer type information if that pointer type has some kind of direct semantic meaning -- say, if the pointer element type affects the call ABI in some way. If it does not have direct semantic meaning, then deriving the pointer type based on usage (as DXIL does) and using that for emission would be right approach.

I guess the problem might be that we can't always derive the type, for example if we have a translation unit:

  extern void foo(int * ptr);
  kernel void k(int * ptr) {
    foo(ptr);
  }

then if in another translation module you have something like:

  void foo(int * ptr){
    *ptr = 1;
  }

For this program `foo` will translate into SPIR-V with different function prototype because in the first unit the type can't be deduced or deduced to some default type but in the second case it is deduced to the exact type. So the functions in two modules will have two different prototypes when mapped into SPIR-V and therefore linking won't be resolved?.. while in OpenCL sources it is just the same function `foo`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127579



More information about the cfe-commits mailing list