[SYCL] should inlining work?

[airlied]

This is more of a question, but should I expect inlining to work?

clang++ -O1 -finline-functions -std=c++11 -fsycl simple-sycl-app.cpp -o simple-sycl-app -lsycl -lOpenCL

should the SYCL get all methods inlined?

[airlied]

I've traced it down to the -disable-llvm-passes in clang/lib/Driver/ToolChains/Clang.cpp: around 3522.

[airlied]

I've removed that line, and wow the spir-v the compiler produces is a lot nicer at least for the sample app, is there some reason we have this disable there?

[keryell]

I think it is a constraint about SPIR-V. SPIR-V people are very keen to manage their own optimizations themselves, because they want to keep structured control flow and things like that. This might be OK for the typical low-level languages used in graphics shaders.
The problem is that for languages like modern C++, if there is no aggressive optimizations in use, the code might be pretty inefficient.
In our case, for our SPIR-df path, we use basically full -O3 to avoid leaving performance on the table.

[airlied]

The current code just outputs unstructued CFG anyways, we have hacked a structurizer pass into a fork of llvm-spirv just to avoid this.

If we do want to control the opts, then we should at least build a set of useful ones that need to get executed, inlining and copy elimination are definite requirements to produce useful SPIR-V.

[keryell]

That seems like a good plan.

[bader]

I'd like to clarify a few issues with running standard optimization pipeline:

• there are passes breaking SPMD programming model (http://llvm.1065342.n5.nabble.com/llvm-dev-RFC-Adding-thread-group-semantics-to-LangRef-motivated-by-GPUs-td124656.html)
• SPIR-V translator is validated only with O0 LLVM IR, but it's technical issue.
• I'm not sure if we can adequately evaluate if particular transformation is safe at SPIR-V level or not w/o mapping the desicion on particular architecture set. E.g. inlining might be required for GPU, but hurt the performance on CPU.

Eventually it would be great to have both options supported:

• emit unoptimized SPIR-V and let OpenCL back-end to run target specific optimizations
• support AOT compilation mode where we know particular architecture and can run standard optimization pipeline.

[keryell]

Yes, it would be great to have a way to specify some options to have aggressive AOT compilation.

[bader]

5976ff0 enabled inlining in JIT mode, so now we should have inlining working for both JIT and AOT modes.
@airlied, I'm closing this issue. Let me know if anything else is missing.