I managed to resolve the issue. The problem seems to be directly related with the COFF object format and how a linker works with it (Windows). The llvm::RuntimeDyldCOFFX86_64 only resolves external symbols correctly if the code has been generated with llvm::CodeModel::Large. https://groups.google.com/forum/#!searchin/llvm-dev/IMAGE_REL_AMD64_REL32/llvm-dev/Z_xAyjlNWZo/h3L3aggnDgAJ
Here another solution is proposed involving inserting some jump stubs but I guess this is for the LLVM RuntimeDyld devs. http://lists.llvm.org/pipermail/llvm-dev/2015-November/092727.html I have barely tested on Windows, but the JIT seems to work now as expected. On Friday, 16 February 2018 11:31:08 UTC+1, Ivan Alduan wrote: > > The main goal is to be able to compile and execute code generated at > runtime inside an application with ISCP. > > I guess you can distribute ispc.exe an make interprocess calls using stdin > as input to ispc.exe and compile IR to an intermediate file, then load this > file and JIT. > But being ISPC open source could be very easy to replace ispc.exe for > another one that dumps any raw source code call to files. That is not good > I guess. > > The same is true for CUDA, you can make a process call to nvcc but the > CUDA API also provides NVRTC. OpenCL or Vulkan also allows you to build > everything within the process. > I prefer this approach and keep everything inside the box. > > Still, the runtime link problem I am having would be there with Brian > approach. > > Last thing I have tried is to mark these function declarations within ISPC > util.m4 with "dllimport ccc", provide addresses of the 3 functions from a > dll to llvm::sys::DynamicLibrary and still I am having relocation overflow. > I am missing something :(. > > > On Thursday, 15 February 2018 20:15:13 UTC+1, Brian Green wrote: >> >> What is the advantage of this approach versus using the ispc compiler to >> generate a .bc that you then JIT using the LLVM API? >> >> -Brian >> >> On Thursday, February 15, 2018 at 7:33:15 AM UTC-8, Ivan Alduan wrote: >>> >>> Hello, >>> >>> I am trying to create a JIT version of the ISPC compiler (without >>> modifying offline behavior). >>> The branch is public and I would love to work together to integrate >>> changes into the master once the interface is more stable, >>> https://github.com/ivalduan/ispc/tree/llvm_orc_jit >>> >>> ispc::ispcInit(); >>> >>> ispc::TargetOptions topt; >>> ispc::Target * target = new ispc::Target(topt, true); >>> >>> ispc::Module * module = new ispc::Module("main"); >>> module->SetTarget(target); >>> >>> int err; >>> err = module->Compile(sourceStr); >>> >>> ispc::IspcJIT * ispcJit = new ispc::IspcJIT; >>> err = ispcJit->initExecutionEngine(target); >>> ispc::IspcJIT::ModuleHandle H = ispcJit->addModule(module); >>> >>> llvm::JITSymbol sym1 = ispcJit->findSymbol("main_ispc"); >>> assert(sym1 && "Function not found"); >>> llvm::JITTargetAddress addr1 = llvm::cantFail(sym1.getAddress()); >>> ... >>> >>> ispc::ispcTerminate(); >>> >>> As far as I do not need external symbols everything works as expected, >>> the problem is JIT compiling kernels with calls to ISPCAlloc, ISPCLaunch >>> and ISPCSync. Those symbols are statically linked into the library calling >>> the JIT. >>> >>> I figured out that I need to add the external symbols with >>> llvm::DynamicLibrary::AddSymbol(..) at runtime in order to be able to find >>> them, but after finding them I am having resolve issues ("Relocation >>> overflow"), file RuntimeDyldCOFFX86_64.h. >>> This is the function that adds the external symbols. >>> >>> void ispcJitAddExplicitSymbols() { >>> llvm::sys::DynamicLibrary::AddSymbol("ISPCAlloc", &ISPCAlloc); >>> llvm::sys::DynamicLibrary::AddSymbol("ISPCLaunch", &ISPCLaunch); >>> llvm::sys::DynamicLibrary::AddSymbol("ISPCSync", &ISPCSync); >>> } >>> >>> I am new to the COFF object format but I guess I need somehow to >>> indicate that those symbols are not internal when they are added to a >>> module as builtin functions with ISPC. >>> Could anyone knowing better than me all the machinery give me some hints? >>> >>> Thanks. >>> >>> -- You received this message because you are subscribed to the Google Groups "Intel SPMD Program Compiler Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
