similar to: [LLVMdev] getPointerToGlobal() / MCJIT

As far as I know, no one is working to fix the test case in question. Patches welcome :) Cheers, Dan On 2012-11-13, at 1:29 AM, "Armin Steinhoff" <armin at steinhoff.de> wrote: > > Hi all, > > are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? > (see for details the

Daniel, I didn't find the MCJIT directory under unitests/ExecutionEngine ... there is only a directory called JIT. You mean this directory ? Many thanks --Armin Malea, Daniel wrote: > Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT > > The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. > >

It's definitely there. It was added in r165246 recently so you probably have an older version. Amara On 13 October 2012 23:02, Armin Steinhoff <as at steinhoff-automation.com> wrote: > Daniel, > > I didn't find the MCJIT directory under unitests/ExecutionEngine ... there > is only a directory called JIT. > You mean this directory ? > > Many thanks > >

Hi Armin, Argument parsing isn't handled by the JIT. This sounds like you're making redundant calls to cl::ParseCommandLineOptions ? Deleting the ExecutionEngine and any RTDyldMemoryManager instances that you've created should be enough to reset the JIT. Cheers, Lang. On Tue, Jan 20, 2015 at 12:38 PM, Armin Steinhoff <armin at steinhoff.de> wrote: > > Hi, > >

Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. Good luck, Dan On 2012-10-13, at 4:57 AM, "Armin Steinhoff" <as at steinhoff-automation.com> wrote: > > Kaylor, > > do you have some good documented example code which shows the usage of

Kaylor, do you have some good documented example code which shows the usage of the MCJIT ? This would help a lot ... the sematic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an

Hi all, are there any plans to correct/implement the "getPointerToGlobal()" method for accessing global variables that are emitted by MCJIT? (see for details the unit test of MCJIT) Best Regards Armin

Hi Armin, > The MCJIT API can only be used once to JIT compile external souces to excuteable code into the address space of a running process. I'm not sure exactly what you mean by "can only be used once" in this context. Regardless, the new APIs are definitely designed to make it easier to lead, unload and replace modules, and I hope they will support a wider range of use cases

> From: Armin Steinhoff [mailto:armin at steinhoff.de] > Subject: Re: [LLVMdev] New JIT APIs > is >  delete EE;   // execution engine >  llvm_shutdown(); > sufficient ? AFAICT, llvm_shutdown() must not be called unless you reach a point where LLVM will not be used again by the process (e.g., termination), as it destroys statically allocated objects. We delete the

Thanks all for replying! I'll try the CostModel class first. Jingyue On Thu, Jan 15, 2015 at 3:47 AM, Jonas Wagner <jonas.wagner at epfl.ch> wrote: > Hi, > > 3. CostModel::getInstructionCost::getInstructionCost in >> lib/Analysis/CostModel.cpp >> > > I've been using the CostModel class in a project, and it has worked quite > well. I don't have

On Thu, Jun 12, 2014 at 10:57:46AM +0200, Armin Steinhoff wrote: > > Hi, > > first problem was: > > >FileManager.cpp:311:21: error: range-based ‘for’ loops are not allowed > >in C++98 mode > >for (auto & fe: SeenFileEntries) { > >^ > >FileManager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’, > >which is of non-class type ‘int’

I'm having some trouble getting access to a global variable with getPointerToGlobal. The resulting value is not what I am expecting. My assembly looks something like this: @gresult = global i32 undef define i32 @eval_expr() { entry: ... store i32 %3, i32* @gresult ret i32 %3 } Where "gresult" is created with: auto global = new llvm::GlobalVariable( *module, int32Type,

Hi all, I need to run c++ prgrams using lli. However, I find lli cannot handle the alias instruction correctly. Following is an example: ------------ example.cc ------------- #include <iostream> using namespace std; class cls { public: cls(); ~cls(); }; cls::cls() { cout << "constructor" << endl; }; cls::~cls() { cout <<

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

I believe the perf tool cannot profile/analyze the JITed code in MCJIT model. Can you please confirm this ? I was working on a patch to fix this. Another question, is the there any support to map the llvm IR with x86 generated assembly ? so its easier to analyze the code generator. -------------- next part -------------- An HTML attachment was scrubbed... URL:

While using MCJIT, when I define a function with name Fn_.._lib_rc-variant.lp0_17_0x706970 ExecutionEngine::getPointerToFunction fails to locate it (returns 0). There is no problem if the function is named Fn_0x706970. There is no problem with those names using the traditional JIT. Is there any special limitation on function names for MC/MCJIT?

Hi, I'm building LLVM IR. I'd like to compile this IR to native code (I don't want JIT) and immediately load it to execute. So far, I've the following: 1) I can emit the IR to native assembly/object file doing the same thing llc does (using TargetMachine::addPassesToEmitFile). 2) I can dynamically load a precompiled .so file (using llvm::sys::DynamicLibrary::getPermanentLibrary),

Hello! I was trying to optimize our automatically generated backend for Open RISC and for this purpose I went through the gcc torture testsuite. There are many programs that are better optimized by LLVM, but some are much better optimized by gcc 4.9. The main limitations were is loop unrolling and structures handling. Differences can be best seen e.g. when compiling for an

>Since MCJIT works on x86, please don't remove it from the supported >platforms list. One downside of using the macro trick is that the test names >are still printed even when they are disabled. It sounds like you need to >modify the macro to also check for the target triple as well... This was just a temporary change to see how it works. >There isn't anything in MCJIT as

Hi Jyotsna, Currently there's a preprocessor trick that prevents llvm/unittests/ExecutionEngine/MCJIT tests from running on architectures and operating systems that are known to fail. Specifically, check out the functions OSSupportsMCJIT() and ArchSupportsMCJIT() functions in unittests/ExecutionEngine/MCJIT/MCJITTestBase.h, and the corresponding macro SKIP_UNSUPPORTED_PLATFORM that is used