[SYCL][Question]Unexpected call to llvm.is.constant.i64 on Ubuntu 19.10

[LeicongLi]

Hi,
May I ask a question as the title described?
When compiling with DPCPP on Ubuntu 19.10, it throws an error message as follows. The same program works fine on Ubuntu 18.04, and I would like to try to write a simple case to reproduce, but I have no idea about under which condition the function will be called, and what makes it an Invalid FunctionCall.
Could you please share same information? Thanks!

InvalidFunctionCall: Unexpected llvm intrinsic: llvm.is.constant.i64 [Src: /xxx/llvm/llvm-spirv/lib/SPIRV/SPIRVWriter.cpp:1997 ]
llvm-foreach:
clang: error: llvm-spirv command failed with exit code 1 (use -v to see invocation)

[bader]

[SYCL][MLIR][Question]Unexpected call to llvm.is.constant.i64 on Ubuntu 19.10

How is this related to MLIR?

When compiling with DPCPP on Ubuntu 19.10, it throws an error message as follows. The same program works fine on Ubuntu 18.04, and I would like to try to write a simple case to reproduce, but I have no idea about under which condition the function will be called, and what makes it an Invalid FunctionCall.

I don't think OS version is really matters here, but I suspects that it might be related to C++ development toolchain. What libstdc++/GCC installations are used in both cases? If it's some default version, it looks like new version of the standard C++ library (installed with Ubuntu 19.10) makes use of some compiler built-in function, which DPPC++ compiler is not able to translate to SPIR-V format.

[MrSidims]

The error comes from LLVM IR to SPIR-V translator means, that this LLVM intrinsic has no analogs in SPIR-V.

@bader @AlexeySotkin that it's not unique issue that users might face, I suggest to add spirv-allow-unknown-intrinsics in DPCPP driver to add as opt to llvm-spirv tool. This option will allow the translator to translate unknown LLVM intrinsic to external functions, what do you think?

[bader]

The error comes from LLVM IR to SPIR-V translator means, that this LLVM intrinsic has no analogs in SPIR-V.

@bader @AlexeySotkin that it's not unique issue that users might face, I suggest to add spirv-allow-unknown-intrinsics in DPCPP driver to add as opt to llvm-spirv tool. This option will allow the translator to translate unknown LLVM intrinsic to external functions, what do you think?

I don't think it's a good idea, because resulting SPIR-V won't conform to the spec and most likely will lead to runtime errors, which are much more difficult to analyze.

[AlexeySotkin]

In general I agree with @bader. But maybe it makes sense for the user, to have a possibility to use spirv-allow-unknown-intrinsics if they want and if they know what they are doing. For experimental purposes for example.

[LeicongLi]

Thanks for all provided information.
@bader Thanks, and apologize for the late reply. I checked the default version of Ubuntu, my 18.04 uses gcc-7 while 19.10 uses gcc-9. The error showed up again after I re-compile using gcc-7 on 19.10. Any other development tools you suspect?

Ubuntu 19.10 GCC info

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~19.10' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~19.10) 


$ /sbin/ldconfig -p | grep stdc++
libstdc++.so.6 (libc6,x86-64) => /lib/x86_64-linux-gnu/libstdc++.so.6

Ubuntu 18.04 GCC info

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 


$ /sbin/ldconfig -p | grep stdc++
libstdc++.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
libstdc++.so.6 (libc6) => /usr/lib32/libstdc++.so.6

[bader]

I think just installing GCC 7 is not enough, clang still picks up the headers from the latest GCC installation. You can confirm that by adding -### to your build command. You can specify GCC toolchain by using --gcc-toolchain= option.

[LeicongLi]

Thanks @bader , you are right. It picks the latest gcc.
By using provided solution, I am able to compile my program.
However, its tricky to select the desired gcc toolchain. I need to keep a new file space described in the post (https://stackoverflow.com/a/41982109/3754605).
Do you have a better method?

With your help, we located the problem to dpcpp using gcc-9. Would you mind to provide a further direction to find out which built-in used in gcc-9 is not recognized by dpcpp?

[bader]

Thanks @bader , you are right. It picks the latest gcc.
By using provided solution, I am able to compile my program.
However, its tricky to select the desired gcc toolchain. I need to keep a new file space described in the post (https://stackoverflow.com/a/41982109/3754605).
Do you have a better method?

+@mdtoguchi

With your help, we located the problem to dpcpp using gcc-9. Would you mind to provide a further direction to find out which built-in used in gcc-9 is not recognized by dpcpp?

__builtin_constant_p is producing this intrinsic.

[mdtoguchi]

As /usr is the default search location, clang will always use the latest version found. You can create a new file space with the version you want to grab, or you can install gcc in a different location and use --gcc-toolchain or --sysroot to point to that location.

[LeicongLi]

Hi @bader , could you help to direct me to reproduce the bug using a command? I am still getting familiar with dpcpp, but would like to create a small case to file a bug to support my product soon. Thank you.

[bader]

The command should be as simple as clang++ -fsycl reproducer.cpp or dpcpp reproducer.cpp. I think the trick here is to capture environment and source code triggering this issue.

[AGindinson]

Will be resolved by the pulldown of KhronosGroup/SPIRV-LLVM-Translator#916.