SPIRVReader: reverse-translated argument types differ from clang output since opaque pointers

[svenvh]

The LLVM argument type for any of the OpenCL "Other Built-in Data Types" (such as image types) has changed since the transition to opaque pointers. This only affects the OpenCL target env modes of llvm-spirv.

For example, for the following OpenCL C kernel:

kernel void foo(image2d_t img, global int *out) {
  *out = get_image_channel_data_type(img);
}

clang -target spir currently generates:

call spir_func i32 @_Z27get_image_channel_data_type14ocl_image2d_ro(target("spirv.Image", void, 1, 0, 0, 0, 0, 0, 0) %img)

Generating SPIR-V from the above kernel using clang -c --target=spirv64 and taking the SPIR-V through llvm-spirv -r gives:

call spir_func i32 @_Z27get_image_channel_data_type14ocl_image2d_ro(ptr addrspace(1) %img)

That is, the mangled function name remains the same, but the image argument has become a plain pointer instead of a TargetExtType.

My proposal would be to align to clang as closely as possible, so for this case we'd ideally generate TargetExtTypes instead of pointers.

[svenvh]

@MrSidims I suppose you're mostly interested in SPIR-V friendly IR so this would not affect you, but would be good to know if you have any concerns/thoughts about making this change.

[MrSidims]

@svenvh no concerns, I'm actually surprised to see, that opaque ptr is being generated in this case and not target extension type.

@wenju-he FYI

[wenju-he]

My proposal would be to align to clang as closely as possible, so for this case we'd ideally generate TargetExtTypes instead of pointers.

+1

Intel OpenCL CPU device is using SPIR-V friendly IR, but the device calls SPIRV::SPIRVToOCL20Pass to convert SPIR-V friendly IR into the IR form of OpenCL target env since the backend built-in are written in the form of OpenCL target env.
I think we can make corresponding adjustment to the argument type to the built-in implementation in Intel OpenCL CPU device for the change.

[svenvh]

I've opened the first patch in the series addressing this issue for image and sampler types: #3293

More patches will follow for the other special types.