Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SYCL] noexcept specifier device side ICE in LLVM-SPIRV #77

Closed
agozillon opened this issue Apr 11, 2019 · 4 comments
Closed

[SYCL] noexcept specifier device side ICE in LLVM-SPIRV #77

agozillon opened this issue Apr 11, 2019 · 4 comments
Labels
bug Something isn't working

Comments

@agozillon
Copy link
Contributor

agozillon commented Apr 11, 2019

#include <CL/sycl.hpp>
using namespace cl::sycl;
class exceptions_on_device;

template <typename T>
void invoke(T func) noexcept {
  func();
}

int main() {
  queue q;
  buffer<int> ob(range<1>{1});
  q.submit([&](handler &cgh) {
      auto wb = ob.get_access<access::mode::write>(cgh);
      cgh.single_task<exceptions_on_device>([=]() {
        invoke([&]() {
            wb[0] += 2;
          }
        );
      });
  });
  q.wait();
  return 0;
}

So, in the example above I'm passing a lambda to a function marked with a noexcept specifier that then invokes the lambda. So nothing fancy, but perhaps I'm doing something silly or the above is not legal SYCL in some way.

In either case case, this example will compile without the noexcept on the invoke function, but ICE with noexcept on the invoke function (it will also ICE if I put noexcept on the passed in lambda as well). I've attached the ICE to the bottom of the issue. I imagine even if this isn't legal in someway it shouldn't lead to an ICE, perhaps a diagnostic of some kind?

The compiler invocation I used in this case was:
$ISYCL_BIN_DIR/clang++ -std=c++11 -fsycl device_side_exception.cpp -o device_side_exception -lOpenCL

I dug into this one a bit, the LLVM-SPIRV translator seems to break on an LLVM landing pad call instruction and it's possible to get the example to compile with noexcept on the function by appending -fno-exceptions alongside the previous command.

I did a quick fix based on this and modified line 2839 of clang/lib/Frontend/CompilerInvocation.cpp to disable exceptions for the device similar to OpenMP+NVPTX and OpenCL C++. Maybe this isn't an ideal fix in this case however, and I'm missing the bigger picture though.


**$ISYCL_BIN_DIR/clang++ -std=c++11 -fsycl  device_side_exception.cpp -o device_side_exception -lOpenCL**

Stack dump:
0.	Program arguments: /storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv -spirv-no-deref-attr -o /tmp/device_side_exception-136eb4.out /tmp/spir64-linked-2d4ccd.bc 
1.	Running pass 'LLVMToSPIRV' on module '/tmp/spir64-linked-2d4ccd.bc'.
 #0 0x000055c117a3a65a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x41465a)
 #1 0x000055c117a38554 llvm::sys::RunSignalHandlers() (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x412554)
 #2 0x000055c117a386d5 SignalHandler(int) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x4126d5)
 #3 0x00007fdad51fcdd0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12dd0)
 #4 0x000055c1179cac60 llvm::Value::getName() const (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x3a4c60)
 #5 0x000055c11772365b SPIRV::LLVMToSPIRV::transCallInst(llvm::CallInst*, SPIRV::SPIRVBasicBlock*) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0xfd65b)
 #6 0x000055c117724ef2 SPIRV::LLVMToSPIRV::transValueWithoutDecoration(llvm::Value*, SPIRV::SPIRVBasicBlock*, bool) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0xfeef2)
 #7 0x000055c117725014 SPIRV::LLVMToSPIRV::transValue(llvm::Value*, SPIRV::SPIRVBasicBlock*, bool) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0xff014)
 #8 0x000055c117729b31 SPIRV::LLVMToSPIRV::transFunction(llvm::Function*) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x103b31)
 #9 0x000055c117729f70 SPIRV::LLVMToSPIRV::translate() (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x103f70)
#10 0x000055c11772a0bc SPIRV::LLVMToSPIRV::runOnModule(llvm::Module&) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x1040bc)
#11 0x000055c1179a11e2 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x37b1e2)
#12 0x000055c11772a13d llvm::writeSpirv(llvm::Module*, std::ostream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x10413d)
#13 0x000055c1176c9e6d convertLLVMToSPIRV() (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0xa3e6d)
#14 0x000055c1176b8377 main (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0x92377)
#15 0x00007fdad48a909b __libc_start_main /build/glibc-B9XfQf/glibc-2.28/csu/../csu/libc-start.c:308:16
#16 0x000055c1176c90ba _start (/storage/ogozillo/intel-sycl/no-mod/sycl/build/bin/llvm-spirv+0xa30ba)
clang-9: error: unable to execute command: Segmentation fault
/usr/bin/ld: /tmp/device_side_exception-0688e3.o: file not recognized: file truncated
clang-9: error: sycl-link command failed due to signal (use -v to see invocation)
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
clang version 9.0.0 (https://github.com/intel/llvm.git 39e2c74a39cd72b9830e8945bc03ac73d20ed410)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /storage/ogozillo/intel-sycl/no-mod/sycl/build/bin
clang-9: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
@bader bader added the bug Something isn't working label Apr 11, 2019
@bader
Copy link
Contributor

bader commented Apr 11, 2019

@agozillon thank you for reporting this.
I think your analysis is correct and device code should be compiled with -fno-exceptions.
We can apply your suggestion and add one more case to line 2839 of clang/lib/Frontend/CompilerInvocation.cpp - if ( or ) { // disable extensions.

I thought we already fixed this bug in the driver by explicitly setting -fno-exceptions for device compiler.

@agozillon
Copy link
Contributor Author

No problem! I'm glad that it's hopefully a simple fix.

And yes, I remember reading some -fno-exceptions/exception disabling related commits at some point, can't seem to track the change down though so perhaps my memory is incorrect in this case.

@agozillon
Copy link
Contributor Author

agozillon commented Apr 12, 2019

It won't be as simple as my suggested quick fix unfortunately, it will fix the problem stated in this issue but it seems to cause a different issue, that I didn't realize until I ran the unit tests (should have done that previously, it slipped my mind I was a little focused on our own use case, I apologize).

Altering the compiler as I suggested will cause several tests in the SYCL test cases to break as they make use of perfectly legal host side try/catch, one example would be SYCLUnitTests :: basic_tests/queue.cpp.

Forcing no exceptions for the device compiler seems to have the side affect of causing error diagnostics on the host try/catches as the device compiler still has to compile the whole source, including exception code which is classified as a compile error when fno-exceptions is flagged. At least that's what I believe from my current understanding.

If this is the case I suppose, you could in theory turn off certain hard diagnostics related to the device compiler but I don't imagine that'd be considered particularly clean.

@bader bader added upstream This change is related to upstreaming SYCL support to llorg. and removed upstream This change is related to upstreaming SYCL support to llorg. labels Jun 18, 2019
@ilyastepykin
Copy link
Contributor

Already fixed by #449

aelovikov-intel pushed a commit to aelovikov-intel/llvm that referenced this issue Feb 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants