[SYCL] Question on address space inference

[agozillon]

So I've been tinkering with the new address space inference method, but ran into some difficulties. Namely that I foolishly forgot there was a pass recipe required to resolve the address spaces from generic into concrete address spaces. I brought this up recently and @bader explained it to me quite well.

So I would like to know if possible please:

1. The required set of passes that should be ran on the LLVM IR to achieve the resolution from generic to concrete (we currently run -O3 but perhaps it doesn't contain all the passes that are required, e.g. the InferAddressSpaces Pass)
2. If the InferAddressSpaces pass that currently exists upstream is good enough for the concrete address space resolution or if the Intel Backend version has some modifications to it that are required for this to fully function?

I believe it was mentioned that @asavonic is the right person to answer these questions! Thank you very much for your answers and help on this.

[asavonic]

The required set of passes that should be ran on the LLVM IR to achieve the resolution from generic to concrete (we currently run -O3 but perhaps it doesn't contain all the passes that are required, e.g. the InferAddressSpaces Pass)

InferAddressSpaces (IAS) pass is not enabled by default in opt. IIRC it is supposed to be enabled by a target (e.g. it is enabled for amdgcn target).

If the InferAddressSpaces pass that currently exists upstream is good enough for the concrete address space resolution

I'd say that IAS pass works pretty good on the tests I looked at, but it has a few limitations: 1) the pass analyses only one function at a time and does not analyse the whole call graph, 2) it does not look into pointer stores/loads from memory, and 3) it does not do control flow analysis.

Depending on the compilation flow and use-cases you want to cover, these limitation may or may not be significant. For example, Intel OpenCL Backend for CPU does aggressive inlining, so (1) almost never a problem, and standard LLVM optimization passes (mem2reg, sroa) usually clean up excessive loads/stores, so (2) is only an issue when user have pointer load/stores that cannot be trivially removed. We cannot do much about (3), it essentially requires OpenCL 2.0 GAS to be supported.

if the Intel Backend version has some modifications to it that are required for this to fully function

We have a few minor tweaks: an option to force the "flat" (generic) address space number, and support for rewriting of OpenCL builtins from generic to concrete overloadings (the IAS pass in llvm.org can only work with LLVM intrinsics).

[Ruyk]

@asavonic When there is a generic pointer "leaking" , is that an error on the compiler or something for your SPIRV consumers to solve?

[asavonic]

@asavonic When there is a generic pointer "leaking" , is that an error on the compiler or something for your SPIRV consumers to solve?

When a generic pointer is present in SPIR-V (LLVM IR) after Clang, SPIR-V consumers (OpenCL backends) are supposed to either optimize it away using IAS pass or equivalent, or support generic address space pointers in hardware.

[keryell]

The problem is when you write non-trivial C++ code with lambdas of lambdas for example you can end up with a lot of double pointers before aggressive optimization. So we end up with non OpenCL 1.2 code at the end, while if we just use -O3 or so, these pointers might just disappear, like a lot of other dead code...
Can a SYCL compiler can pass the CTS if it does not work on an OpenCL 1.2 implementation?

[agozillon]

This can probably be closed now unless there is still some on going discussion, I managed to put some time into integrating it recently and it seems to work reasonably well minus some edge cases for now!

Thank you very much for the help and information pointing us in the right direction.