sycldevice-binding.bc Generation Fix, sycl branch (2020.07.13.)

[krasznaa]

While trying to build the tip of the sycl branch with

cmake -DCMAKE_BUILD_TYPE=Release \
   -DCMAKE_INSTALL_PREFIX=<FOO> \
   -DLLVM_TARGETS_TO_BUILD="X86" -DLLVM_EXTERNAL_PROJECTS="llvm-spirv;sycl;libdevice" \
   -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt;lld;openmp;llvm-spirv;sycl;libclc" \
   -DLLVM_EXTERNAL_LLVM_SPIRV_SOURCE_DIR=<BAR> \
   -DLLVM_EXTERNAL_SYCL_SOURCE_DIR=<FOO> \
   -DLLVM_EXTERNAL_LIBDEVICE_SOURCE_DIR=<BAR> \
   -DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_PIC=ON -DLLVM_ENABLE_RTTI=ON \
   -DOpenCL_INCLUDE_DIRS= -DOpenCL_LIBRARIES= -DOpenCL_INSTALL_KHRONOS_ICD_LOADER=TRUE ../llvm/llvm/

, I ran into the following kind of failures:

[ 83%] Generating sycldevice-binding-nvptx64--/sycldevice-binding.bc
 Scanning dependencies of target builtins.link.clc-nvptx64--
 [ 83%] Building CLC object tools/libclc/CMakeFiles/builtins.link.clc-nvptx64--.dir/convert-clc.bc
 [ 83%] Building CLC object tools/libclc/CMakeFiles/builtins.link.clc-nvptx64--.dir/ptx/lib/math/nextafter.bc
 error: unable to open output file '/root/build/tools/libclc/sycldevice-binding-nvptx64--/sycldevice-binding.bc': 'No such file or directory'
 1 error generated.
 make[2]: *** [tools/libclc/sycldevice-binding-nvptx64--/sycldevice-binding.bc] Error 1
 make[1]: *** [tools/libclc/CMakeFiles/builtins.link.libspirv-nvptx64--.dir/all] Error 2
 make[1]: *** Waiting for unfinished jobs....

I traced them down to a shortcoming in the recently introduced add_libclc_sycl_binding(...) function. With this change added I was able to build the code successfully once again.

[bader]

I would recommend using configure.py to build make/ninja build system files (see get started guide).

Just out of curiosity: why do you build libclc with X86 target?
AFAIK, libclc library is used by CUDA back-end only, so I would expect you to build NVPTX target as well or don't build libclc at all.
See https://github.com/intel/llvm/blob/sycl/buildbot/configure.py#L35-L39

[krasznaa]

The example was not a great one... I just wanted to show what I did "locally" to reproduce a problem that I saw at first during a Docker image build. For that image I use the following configuration:

    && cmake -DCMAKE_BUILD_TYPE=Release                                       \
       -DCMAKE_INSTALL_PREFIX=${LLVM_INSTALL_DIR}                             \
       -DLLVM_TARGETS_TO_BUILD="X86;NVPTX"                                    \
       -DLLVM_EXTERNAL_PROJECTS="llvm-spirv;sycl;libdevice"                   \
       -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;compiler-rt;lld;llvm-spirv;sycl;libclc" \
       -DLLVM_EXTERNAL_LLVM_SPIRV_SOURCE_DIR=${LLVM_SOURCE_DIR}/llvm-spirv    \
       -DLLVM_EXTERNAL_SYCL_SOURCE_DIR=${LLVM_SOURCE_DIR}/sycl                \
       -DLLVM_EXTERNAL_LIBDEVICE_SOURCE_DIR=${LLVM_SOURCE_DIR}/libdevice      \
       -DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_PIC=ON -DLLVM_ENABLE_RTTI=ON         \
       -DSYCL_BUILD_PI_CUDA=ON                                                \
       -DLIBCLC_TARGETS_TO_BUILD="nvptx64--;nvptx64--nvidiacl"                \
       -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda                                \
       -DCMAKE_PREFIX_PATH=${CUDA_DRIVER_DIR}                                 \
       -DGCC_INSTALL_PREFIX=${GCC_INSTALL_DIR}                                \
       ${LLVM_SOURCE_DIR}/llvm/                                               \

[bader]

Interesting...
@Naghasan, any ideas how it's working w/o this change? Is this some data race?

[Naghasan]

Interesting...
@Naghasan, any ideas how it's working w/o this change? Is this some data race?

no idea ... it always worked fine on our machines.

The change make senses to me (but I'm no CMake expert).

[krasznaa]

It's clear that the CI doesn't build libclc in any of its configurations. (At least it doesn't show up in this PR's logs as far as I can tell.) That's why this issue didn't show up there.

As to why it didn't show up in @Naghasan's configuration: You use Ninja, don't you? Since I was very surprised to find just now, that Ninja is creating that directory automatically for you. For some reason... 😕 But with GNU Make you have to be explicit about creating it.

I guess I also learned something new from this...

[Naghasan]

It's clear that the CI doesn't build libclc in any of its configurations. (At least it doesn't show up in this PR's logs as far as I can tell.) That's why this issue didn't show up there.

It does (buildbot/Lit_With_Cuda), it caught a few refactoring mistake actually :)

As to why it didn't show up in @Naghasan's configuration: You use Ninja, don't you? Since I was very surprised to find just now, that Ninja is creating that directory automatically for you. For some reason... confused But with GNU Make you have to be explicit about creating it.

I do and so does the CI so that's explain why it never showed up.

I guess I also learned something new from this...

nice job catching this