[SYCL][libdevice] Refactor cmake for imf SYCL device library

[jinge90]

Signed-off-by: jinge90 [email protected]

This PR aims to refactor cmake building system for imf SYCL device library. Previously, the source of SYCL fallback device library has pre-assumption that all functions in the same fallback .spv or .o file must reside in single .cpp file. The reason is we need to use sycl compiler to build .spv or .o file with following commands:
clang++ -fsycl -fsycl-device-only -fno-sycl-use-bitcode t.cpp -o t.spv
clang++ -fsycl -c -fsycl-targets="..." t.cpp -o t.o

However, imf fallback sources broke the pre-assumptions, all implementations reside in multiple .cpp files. Current building have to deal with multiple tools, for spv building, we have to do following:

1. use "clang++ -fsycl -fsycl-device-only -c -emit-llvm" to generate LLVM .bc file for each .cpp
2. use "llvm-link" to link multiple LLVM .bc into one LLVM .bc file
3. use "llvm-spirv" to convert the LLVM .bc to spirv file

For .o file, the steps are more complicated, we need to do following:

1. use "clang++ -fsycl -fsycl-device-only -c -emit-llvm" to generate LLVM.bc for each .cpp
2. Use "llvm-link" to link multiple LLVM .bc into one LLVM .bc file
3. the steps 1,2 must be done for all sycl targets supported
4. use clang-offload-bunlder to bundle different sycl target's LLVM .bc to final .objet file

Current solution has following drawbacks:

1. Too complicated, too much unnecessary work which is to emulate the work of simple “clang++ -fsycl …” command. This makes cmake hard to understand and maintain.
2. Too fragile, clang driver may change the detail steps of simple “clang++ -fsycl…” and each tool used currently may update their option and usage which may lead to imf libdevice building failure. The more tools we deal with, the more risk we are in.

So, we decide to use following solution:
For building imf fallback spv or object file, we first combine all required .cpp into a “full” .cpp and then use simple “clang++ -fsycl …” command to build it. We will create a “libdevice” folder in build/lib and save the full .cpp file there.
All imf fallback device library code will be organized to avoid code conflict, duplicate.

[xtian-github]

LGTM

[aelovikov-intel]

@intel/llvm-reviewers-runtime , who is fluent enough in this area to provide meaningful approval?

[akolesov-nv]

Looks appropriate

[jinge90]

Hi, @pvchupin
Could you take a look of this PR?
Thanks very much.

[zettai-reido]

Cmake part looks good.

[pvchupin]

@tcreech-intel, @zhaomaosu, could you please review?

[tcreech-intel]

I think this looks good.

Another approach might be to concatenate with the preprocessor, e.g., by introducing a top-level source which consists only of #include "imf_source.cpp" lines. This could either be generated by CMake from imf_f32_fallback_src_list and imf_fp64_fallback_src_list or checked into sources. In the latter case the CMake is greatly simplified. I don't necessarily prefer this, but thought it might be worth mentioning.

[xtian-github]

Thanks Pavel

[pvchupin]

@jinge90, please address post-commit issues: https://github.com/intel/llvm/actions/runs/2518694462