similar to: [LLVMdev] Machine Code, JIT, and Windows

My understanding was that compiling directly to native code wasn't supported on Windows yet. At least Clang seems to require having GCC in the path on Windows. -----Original Message----- From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Tuesday, May 11, 2010 4:14 PM To: Michael Smith Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Machine Code, JIT, and Windows On Tue, May 11,

Hello Michael, That's for the final linkage. Since the JIT does linking at the bitcode level, it doesn't need to access an external linker AFAIK. --Sam ----- Original Message ---- > From: Michael Smith <Michael.Smith at synopsys.com> > To: Daniel Berlin <dberlin at dberlin.org> > Cc: "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu> > Sent:

On Tue, May 11, 2010 at 6:48 PM, Michael Smith <Michael.Smith at synopsys.com> wrote: > I’m writing an application that generates LLVM byte code and executes it at > runtime. The options I’m looking at are to use the LLVM ExecutionEngine for > JIT execution, or to write an assembly file, link it as a DLL using > gcc/mingw, and load the DLL. It has to work on Linux and Windows.

Before MC, which changes this, LLVM didn't have the ability to assemble its own output into an object file. There is a special code path for the JIT, though, which allows the JIT to encode instructions in memory. It's the difference between being able to make "native code" and being able to make an object file or executable. The plan for the future (maybe this summer?) is to

I have two JIT runs in the same process. First one runs fine. During the second JIT run the exception is thrown, and process catches SEGV after it is thrown and before it is caught. In debugger I see that crash occurs in the function 'classify_object_over_fdes' called from 'init_object' called from 'search_object' called from '_Unwind_Find_registered_FDE'. Crash

Hi, I am using LLVM 3.1, and wants to print the machine code of JIT IR I try the following method EngineBuilder builder(&ctx.getModule()); builder.setEngineKind(EngineKind::JIT); * TargetMachine * tm = builder.selectTarget(); tm->Options.PrintMachineCode = true;* engine = builder.create(); and somewhere in my code, I use runJITonFunction(); Another question is that I am

Please check in an attached patch. Synopsys of the change: fixed the cleanup process of exception information in JIT. Now JIT deregisters registered by it FDE structures allowing consecutive JIT runs to succeed. Note: tools like lli should delete ExecutionEngine object and not the module. Module is deleted by ExecutionEngine. Also I am not sure if this is proper for the module to be owned by

Hi, In ExecutionEngine.cpp, when the JIT or the Interpreter have not been linked in then EngineBuilder::create fails without setting ErrorStr. I've attached a patch to fix this. Warm Regards KS Sreeram -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ee-not-linked-in-msg.diff URL:

On Jun 22, 2009, at 2:19 PM, Kasra wrote: > Hi, > > for some reason I could not get the machine code generator for x86 > working. The interpreter is the only thing that works, is there > anything that I am missing here? This recently changed. In your main program, please #include "llvm/ Target/TargetSelect.h" and call InitializeNativeTarget(); before setting up

On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote: > Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: >

Hi, for some reason I could not get the machine code generator for x86 working. The interpreter is the only thing that works, is there anything that I am missing here? -- Kasra -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090622/89dca208/attachment.html>

Hi Daniel, > Sebastian, this looks like it is most likely some kind of fallout from > your changes. Thanks for letting me know about these failing testcases. In the logs of the buildbot: http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio I see that the bot is configuring llvm with:

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations:

Hi all, I am seeing a number of JIT unit test failures on AArch64. Some googling returns past discussions (circa 2014) but as far as I can tell, everything should be working. I listed the failures below. These are from a Release build. A Debug build does not exhibit the failures. I built with gcc 6.1.0 on SuSE 12. Switching to gcc 8.2.0 also makes the problem go away, both in Debug and

Sorry I meant 0xE8, 0xFF was in my head because of disassembling and seeing it in use, my bad. Ok I didn't thought about PIC, that's a good idea ! ... I forgot it existed at the wrong moment I guess ... How can I modify the GOT then ? Is there an api somewhere in the execution engine / MCJIT ? Or is it somewhere else ? Or I need to accept the idea of hacking stuff inside the LLVM code

I don't see any tests in either test or test-suite for -use-mcjit. Are we not testing this yet? There are lots of other llc options. What is our plan for testing these?

On Mon, Jun 22, 2009 at 4:43 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jun 22, 2009, at 2:19 PM, Kasra wrote: > > Hi, > > for some reason I could not get the machine code generator for x86 > working. The interpreter is the only thing that works, is there > anything that I am missing here? > > This recently changed.  In your main program, please

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC

Hi Lang, That would be great ! :) For now I found a hack which consist of loading a "full of NOP" DLL, use my own DllMemMgr which allocates JIT sections inside the DLL virtual space, backup the memory inside some buffers, unload the DLL, copy the buffer inside the DLL file, create the PDB, reload the DLL file which hopefully in 99% is reloaded at the same virtual address (this allow me

Hi all, Is there way to tell the ORC JIT infrastructure to run the static constructors in a module that has just been compiled? I see that the ExecutionEngine class has a runStaticConstructorsDestructors function, is that relevant with ORC and if so, how should it be accessed? Thanks, Daniele -------------- next part -------------- An HTML attachment was scrubbed... URL: