Unable to compile for targets other than x86_64

I have tried emitting bundles for targets other than x86_64 to no avail. Even i386 is failing. It has something to do with tensor types. I suppose different targets expect/support different tensor types; however, I made sure that my network is using Float32. So this shouldn’t be a problem for i386. The network looks like this:

graph(%input_data : Float(1, 2)
      %1 : Float(8, 2)
      %2 : Float(8)
      %3 : Float(8, 8)
      %4 : Float(8)
      %5 : Float(8, 8)
      %6 : Float(8)
      %7 : Float(1, 8)
      %8 : Float(1)) {
  %9 : Float(1, 8) = onnx::Gemm[alpha=1, beta=1, transB=1](%input_data, %1, %2), scope: FeedForwardNN/Linear
  %10 : Float(1, 8) = onnx::Relu(%9), scope: FeedForwardNN/ReLU
  %11 : Float(1, 8) = onnx::Gemm[alpha=1, beta=1, transB=1](%10, %3, %4), scope: FeedForwardNN/ReLU
  %12 : Float(1, 8) = onnx::Relu(%11), scope: FeedForwardNN/ReLU
  %13 : Float(1, 8) = onnx::Gemm[alpha=1, beta=1, transB=1](%12, %5, %6), scope: FeedForwardNN/ReLU
  %14 : Float(1, 8) = onnx::Relu(%13), scope: FeedForwardNN/ReLU
  %15 : Float(1, 1) = onnx::Gemm[alpha=1, beta=1, transB=1](%14, %7, %8), scope: FeedForwardNN/ReLU
  %output : Float(1, 1) = onnx::Sigmoid(%15), scope: FeedForwardNN/Sigmoid
  return (%output);
}

The traceback that I get when trying to build is:

(base) wny@wny-Macbook ~/sandbox/nn/xgmr/build/debug/bin $ ./x-model-runner -model=/Users/wny/sandbox/nn/pytorch_tuts/ffnn.onnx -network-name=x -model-input-name=input_data -cpu -emit-bundle=../output -target i386
Assertion failed: ((i >= FTy->getNumParams() || FTy->getParamType(i) == args[i]->getType()) && "Calling a function with a bad signature: argument type mismatch."), function createCall, file ../../lib/LLVMIRCodeGen/LLVMIRGen.cpp, line 558.
0  x-model-runner       0x000000010721e0bc llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
1  x-model-runner       0x000000010721e4be SignalHandler(int) + 192
2  libsystem_platform.dylib 0x00007fff713b7b3d _sigtramp + 29
3  libsystem_platform.dylib 0x000000011a0f8938 _sigtramp + 2832469528
4  libsystem_c.dylib        0x00007fff712751c9 abort + 127
5  libsystem_c.dylib        0x00007fff7123d868 basename_r + 0
6  x-model-runner       0x00000001072c7136 glow::LLVMIRGen::createCall(llvm::IRBuilder<llvm::ConstantFolder, llvm::IRBuilderDefaultInserter>&, llvm::Function*, llvm::ArrayRef<llvm::Value*>) + 422
7  x-model-runner       0x00000001072d04e3 glow::LLVMIRGen::generateLLVMIRForInstr(llvm::IRBuilder<llvm::ConstantFolder, llvm::IRBuilderDefaultInserter>&, glow::Instruction const*) + 1603
8  x-model-runner       0x0000000107272111 glow::CPULLVMIRGen::generateLLVMIRForInstr(llvm::IRBuilder<llvm::ConstantFolder, llvm::IRBuilderDefaultInserter>&, glow::Instruction const*) + 2113
9  x-model-runner       0x00000001072c92ed glow::LLVMIRGen::generateLLVMIRForModule(llvm::IRBuilder<llvm::ConstantFolder, llvm::IRBuilderDefaultInserter>&) + 445
10 x-model-runner       0x00000001072718c8 glow::CPULLVMIRGen::generateLLVMIRForModule(llvm::IRBuilder<llvm::ConstantFolder, llvm::IRBuilderDefaultInserter>&) + 40
11 x-model-runner       0x00000001072c448b glow::LLVMIRGen::performCodeGen() + 139
12 x-model-runner       0x000000010727c2c2 glow::BundleSaver::save(llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::SmallVectorImpl<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > const&, llvm::StringRef, llvm::StringRef) 
+ 450
13 x-model-runner       0x00000001072eccd0 glow::LLVMBackend::save(glow::Function*, llvm::StringRef, llvm::StringRef) const + 832
14 x-model-runner       0x00000001071124a4 glow::ExecutionEngine::save(glow::Function*, glow::CompilationOptions const&, llvm::StringRef, llvm::StringRef) + 148
15 x-model-runner       0x0000000106f27e6f glow::Loader::compile(glow::PlaceholderBindings&) + 2415
16 x-model-runner       0x0000000106f4cf85 buildNetwork(glow::Loader&, glow::Type const*) + 117
17 x-model-runner       0x0000000106f4d4a2 main + 242
18 libdyld.dylib            0x00007fff711cced9 start + 1
Abort trap: 6

Ideally, I’d like to be able to compile for the ARM targets (and others supported by LLVM), but understanding why compilation fails even for i386 would be a progress.

Thanks for checking this out! Please post this as an issue on Github here and we can get the right people to take a look.

Ok, for the benefit of those who might hit this issue, it is being tracked here: https://github.com/pytorch/glow/issues/2836.

To summarize: essentially the CPU backend kernels, which is libjit in backends/CPU/libjit has to be compiled for the correct architecture. This can be achieved by adding appropriate flags in backends/CPU/CMakeLIsts.txt for the CPURuntimeCompilationOptions. The sources in libjit may have to be modified/customized for the specific architecture (e.g. some includes may need to be changed or removed).

1 Like