IGC should link in all of its needed LLVM symbols statically (and hide them) to avoid problems with applications linking to an incompatible LLVM dynamically

[pjaaskel]

Currently IGC shipped with the compute runtime seems to refer to some of its needed LLVM symbols dynamically. This causes problems when linking to it from a project which links in LLVM dynamically and the LLVM version is not compatible with the one linked to IGC.

For example, here I try to load the ZE driver from PoCL's LZ driver (dynamically built against LLVM 18) which loads IGC for JIT which then calls LLVM from its SPIRV loader, ending up at some point calling an LLVM 18 symbol:

example1: /home/pjaaskel/src/chipStar/llvm-project/llvm/lib/IR/AttributeImpl.h:96: static void llvm::AttributeImpl::Profile(llvm::FoldingSetNodeID&, llvm::Attribute::AttrKind, uint64_t): Assertion `Attribute::isIntAttrKind(Kind) && "Expected int attribute"' failed.

Thread 9 "example1" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffdcbfb640 (LWP 96916)]
__pthread_kill_implementation (no_tid=0, signo=6, threadid=140736896939584) at ./nptl/pthread_kill.c:44
44	./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140736896939584) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140736896939584) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140736896939584, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x00007ffff7c42476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x00007ffff7c287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x00007ffff7c2871b in __assert_fail_base (fmt=0x7ffff7ddd130 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=0x7ffff1006530 "Attribute::isIntAttrKind(Kind) && \"Expected int attribute\"", 
    file=0x7ffff1006440 "/home/pjaaskel/src/chipStar/llvm-project/llvm/lib/IR/AttributeImpl.h", line=96, function=<optimized out>)
    at ./assert/assert.c:92
#6  0x00007ffff7c39e96 in __GI___assert_fail (assertion=0x7ffff1006530 "Attribute::isIntAttrKind(Kind) && \"Expected int attribute\"", 
    file=0x7ffff1006440 "/home/pjaaskel/src/chipStar/llvm-project/llvm/lib/IR/AttributeImpl.h", line=96, 
    function=0x7ffff10064c8 "static void llvm::AttributeImpl::Profile(llvm::FoldingSetNodeID&, llvm::Attribute::AttrKind, uint64_t)")
    at ./assert/assert.c:101
#7  0x00007fffedd1d3c2 in llvm::FoldingSet<llvm::AttributeImpl>::NodeEquals(llvm::FoldingSetBase const*, llvm::FoldingSetBase::Node*, llvm::FoldingSetNodeID const&, unsigned int, llvm::FoldingSetNodeID&) ()
   from /home/pjaaskel/local/stow/llvm-18-chipstar/lib/libLLVM.so.18.1
#8  0x00007fffe0c2a161 in llvm::FoldingSetBase::FindNodeOrInsertPos(llvm::FoldingSetNodeID const&, void*&, llvm::FoldingSetBase::FoldingSetInfo const&) () from /usr/local/lib/libigc.so.1
#9  0x00007fffe05e3534 in llvm::Attribute::get(llvm::LLVMContext&, llvm::Attribute::AttrKind, unsigned long) ()
   from /usr/local/lib/libigc.so.1
#10 0x00007fffe05e4167 in llvm::AttrBuilder::addAlignmentAttr(llvm::MaybeAlign) () from /usr/local/lib/libigc.so.1
#11 0x00007fffdf7b2d90 in SPIRV::SPIRVToLLVM::transFunctionAttrs(SPIRV::SPIRVFunction*, llvm::Function*) ()
   from /usr/local/lib/libigc.so.1
#12 0x00007fffdf7cae7f in SPIRV::SPIRVToLLVM::transFunction(SPIRV::SPIRVFunction*) () from /usr/local/lib/libigc.so.1
#13 0x00007fffdf7cdf1f in SPIRV::SPIRVToLLVM::translate() () from /usr/local/lib/libigc.so.1
#14 0x00007fffdf7ce120 in llvm::convertSpirvToLLVM(llvm::LLVMContext&, SPIRV::SPIRVModule&, SPIRV::TranslatorOpts const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) () from /usr/local/lib/libigc.so.1
#15 0x00007fffdf7cf71a in llvm::readSpirv(llvm::LLVMContext&, SPIRV::TranslatorOpts const&, std::istream&, llvm::Module*&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) () from /usr/local/lib/libigc.so.1
#16 0x00007fffdf6ffb77 in ?? () from /usr/local/lib/libigc.so.1
#17 0x00007fffdf70030a in ?? () from /usr/local/lib/libigc.so.1
#18 0x00007fffdf702cf1 in ?? () from /usr/local/lib/libigc.so.1
#19 0x00007fffdf99c87b in ?? () from /usr/local/lib/libigc.so.1
#20 0x00007fffdf705db7 in ?? () from /usr/local/lib/libigc.so.1
#21 0x00007fffdf79d94e in ?? () from /usr/local/lib/libigc.so.1
#22 0x00007fffdf7a03dc in ?? () from /usr/local/lib/libigc.so.1
#23 0x00007fffe9409bcf in ?? () from /usr/lib/x86_64-linux-gnu/libze_intel_gpu.so.1

I don't know any other way to solve this problem than link in the LLVM statically or dynamically link to a "standard" LLVM dynlib in the system to which both the app (in this case PoCL) and the driver links. A workaround is to link the LLVM statically to the application (PoCL) which I think is not the correct way as it leads to bloat (all LLVM and IGC/LZ using apps would need to do it).

[eero-t]

This is IGC, not compute-runtime issue, and seems to be fixed based on the linked IGC issue?

PS. IGC can be built with system LLVM, and that's what Linux distributions do with IGC, so this issue concerns only IGC binaries that include their own version. IGC does not support latest LLVM versions yet though:

• LLVM 16 Support intel-graphics-compiler#289
• https://github.com/intel/intel-graphics-compiler/projects/5

[pjaaskel]

I'm not sure if the linked issue fixes this as the problem I reported here is opposite (IGC accidentally calling the app's LLVM symbols, not the app accidentally calling IGC's), but if the LLVM symbols are hidden and internalized and IGC always calls only its own, it could be fixed. Why I reported it here is that indeed it sounded to depend on how the LLVM is linked in and compute runtime builds/packages IGC. I'll reopen if the problem persist across the next release.