search for: emitllvmonlyactions

We have an application that allows the user to compile and execute C++ code on the fly, using Orc JIT v2, via the LLJIT class. And we would like to extend it to allow the user to provide CUDA source code as well, for GPU programming. But I am having a hard time figuring out how to do it. To JIT compile C++ code, we do basically as follows: 1. call Driver::BuildCompilation(), which returns a

Hi, I'm writing to both lists as I'm not sure what the cause of this issue is. I use code like this to compile C source into LLVM IR as suggested on the Clang mailing list previously. class CompileBitcodeAction : public clang::EmitLLVMOnlyAction { protected: Module*& dstModule; public: inline CompileBitcodeAction(Module*& dstModule, LLVMContext* const context = NULL)

...at lists.llvm.org> wrote: > I have made a bit of progress... When compiling CUDA source code in > memory, the Compilation instance returned by Driver::BuildCompilation() > contains two clang Commands: one for the host and one for the CUDA device. > I can execute both commands using EmitLLVMOnlyActions. I add the Module > from the host compilation to my JIT as usual, but... what to do with the > Module from the device compilation? If I just add it to the JIT, I get an > error message like this: > > Added modules have incompatible data layouts: > e-i64:64-i128:128-v16:16-v32:...

Dear All, while willing to assist developers to adhere strictly to coding guidelines, I wrote the attached program called "alias-detector". The program's intent is to utilize the BasicAliasAnalysis to get a list of aliases for each pointer in a certain program code. First it initializes clang as frontend, executes the EmitLLVMOnlyAction, and then processes the produced Module with

I have made a bit of progress... When compiling CUDA source code in memory, the Compilation instance returned by Driver::BuildCompilation() contains two clang Commands: one for the host and one for the CUDA device. I can execute both commands using EmitLLVMOnlyActions. I add the Module from the host compilation to my JIT as usual, but... what to do with the Module from the device compilation? If I just add it to the JIT, I get an error message like this: Added modules have incompatible data layouts: e-i64:64-i128:128-v16:16-v32:32-n16:32:64 (module) vs e-m:...

Oliver Horst wrote: > Dear All, > > while willing to assist developers to adhere strictly to coding guidelines, I > wrote the attached program called "alias-detector". The program's intent is to > utilize the BasicAliasAnalysis to get a list of aliases for each pointer in a > certain program code. First it initializes clang as frontend, executes the >

Heres my full code listing, im totally stuck. // Whistle.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "clang/CodeGen/CodeGenAction.h" #include "clang/Driver/Compilation.h" #include "clang/Driver/Driver.h" #include "clang/Driver/Tool.h" #include

I tried what you said, now I get: LLVM ERROR: Program used external function 'yipee' which could not be resolved! Stack dump: 0. Running pass 'X86 Machine Code Emitter' on function '@main' did not even get as far as a breakpoint. Óscar Fuentes wrote: > > gafferuk <gafferuk at gmail.com> writes: > >> Im confused. The function i wish to call is

gafferuk <gafferuk at gmail.com> writes: > Im confused. The function i wish to call is a return type of int. > Im calling it with int dd = yipee(1); > > What's wrong? Declare the function: int yipee(int); int main() { int dd = yipee(1); return 0; } If that still crashes, put a breakpoint on `yipee' and see if the execution gets there, if the argument is

Hi, I'm not sure if this is a libclang, llvm::cl or clang-interpreter issue so I'll try posting here for a response. I am using libclang as a frontend to the LLVM JIT (3.3 release). I started from the clang-interpreter example and have everything working (given a C/C++ source file I can have it JIT'd to memory and executed) for a single run. When I try to compile a second source