similar to: [LLVMdev] LLVM from .NET

Hi List, I'm trying to upgrade our llvm-c based compiler from JIT to MCJIT. While trying to do so I encountered several problems. Looks like C API does not have proper functions to intialize LLVM with MCJIT. I ended up wrapping the following functions in my own init routine. LLVMInitializeX86TargetInfo(); LLVMInitializeX86Target(); LLVMInitializeX86TargetMC(); LLVMInitializeX86AsmPrinter();

I managed to make it work by cloning code from lli and making my own cpp wrapper. 2013/9/22 Konstantin Olkhovskiy <lupus at oxnull.net> > Hi List, > > I'm trying to upgrade our llvm-c based compiler from JIT to MCJIT. > While trying to do so I encountered several problems. Looks like C > API does not have proper functions to intialize LLVM with MCJIT. > I ended up

Hello All, I'm building an F# binding for LLVM and it seems to be working for the parts of Core and BitWriter that I've tested but I've hit problems with Target/ExecutionEngine. The following test code works with the initializeNativeTarget line commented out like so: <https://github.com/keithshep/llvm-fs/blob/b7050b841108dc703e58563a4cff8845603c950d/test/simpletest2.fs> ...

For those targets supported by LLVM, you can get their TargetData by creating TargetMachine first (take X86 as example): ==== BEGIN CODE SNIPPET ==== const std::string TripleStr = "i686-unknown-linux"; // hard coded for example const std::string FeatureStr = ""; // hard coded for example std::string Err; const Target* T; TargetMachine* TM = NULL; const

It seems that a client application needs to call InitializeNativeTarget or LLVMInitializeNativeTarget before doing any JITting. Unfortunately, LLVMInitializeNativeTarget is defined static inline and does not appear in the .a files; thus a client not written in C or C++ trying to JIT cannot link to the library and call LLVMInitializeNativeTarget that way. It can call a target-specific library

A rebased version of the lld patch is attached. Cheers, Rafael On 31 July 2017 at 15:11, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > Tobias Edler von Koch <tobias at codeaurora.org> writes: > >> Hi Rafael, >> >> On 07/31/2017 04:20 PM, Rafael Avila de Espindola via llvm-dev wrote: >>> However, do we need to start with

Dear all I am trying to get the size of an LLVM pointer type. getPrimitiveSizeInBits() returns 0 for it and the documentation for isSized() suggest to use TargetData. I figured out from Kaleidoscope example that one can get a pointer to TagetData object through the execution engine but it seems to be an overkill. What is the right way to do it? Best regards, Victor -------------- next part

You could compile Speex as a DLL (see libspeex_dynamic.dsp) and use PInvoke. http://en.wikipedia.org/wiki/PInvoke Note that Speex will still be executing as unmanaged code and your program will have the added dependency of the native Speex DLL. It appears that someone created a "Speex.NET" based on JSpeex, but I didn't find any useful info on it. You may want to search for this

On Mon, Jan 4, 2010 at 4:43 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > When implementing a language using LLVM as the backend, it is > necessary to give programs written in that language, access to the C > standard library functions. The Kaleidoscope tutorial shows how to do > this for individual functions using extern declarations, but in > general it would

On Mon, Jan 4, 2010 at 5:41 AM, Kenneth Uildriks <kennethuil at gmail.com>wrote: > On Mon, Jan 4, 2010 at 4:43 AM, Russell Wallace > <russell.wallace at gmail.com> wrote: > > When implementing a language using LLVM as the backend, it is > > necessary to give programs written in that language, access to the C > > standard library functions. The Kaleidoscope

I tried that approach a while ago and failed miserably. Marshalling the structs of structs in the flac lib turned out to be a nightmare (I don't pretend to be an expert, mind you...). I eventually switched to writing my own C# lib from scratch. Work is still under progress. It's no rocket science, I do this a G-job. It has definite limitations (no documentation, decodes only 16-bit files,

I updated the patch to read a call graph from a text file. I tested it with the attached call.txt from lld linking chromium. Unfortunately the resulting lld doesn't seem any faster. One thing I noticed is that the most used symbols seem to be at the end of the file. In any case, can you add tests and send the lld patch for review? Thanks, Rafael On 31 July 2017 at 15:19, Davide Italiano

Anton Korobeynikov wrote: > Hi, Artur > > >> I'm working on that backend now, so probably I'll send some more patches >> soon. I'd be grateful if you could give me some suggestions how to add >> some test for that backend to the test-suite. On Linux the output code >> could be run on Mono and compared with outputs for other backends but >>

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

> On Dec 23, 2014, at 9:45 AM, Chris Lattner <clattner at apple.com> wrote: > > On Dec 22, 2014, at 2:56 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Circling back to Chandler on file size differences. Here are the highlights of what is different. >> >> For my analysis I built LLVM and Clang using a clang built with my

Hi, Artur > So again, one of them makes the global pointers initialization work. > The second one allows executing code with vararg pinvoke functions under > Mono. It generates separate function declaration for each call signature. Is this mono-only feature? Or pretty "universal" one? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint

Hello, As part of a MSIL (i.e. C#) to LLVM frontend I am currently working on ( https://github.com/xen2/SharpLang ), I would need some help/hint about how to properly design "PInvoke callbacks". Through "PInvoke" mechanism .NET allows you to call C functions, i.e.: C#: [DllImport("libc.so")] extern void mempcy(void* dest, void* src, int size); // declaration of C

Hi, I'm having problems linking my project (outside of the llvm source tree) to the LLVM jit. My CMake file contains: ------------ find_package(LLVM REQUIRED) include_directories(${LLVM_INCLUDE_DIR}) link_directories(${LLVM_LINK_DIR}) add_definitions(-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS) add_executable(nvm main.cpp) llvm_config(nvm engine) ------------ cmake succeeds in

These two subclasses of X86TargetMachine are basically identical. The *only* thing that's different is the constructor. And that *only* differs in the is64Bit argument that it passes to the X86TargetMachine constructor. Replacing the hard-coded 'true' or 'false' with 'Triple(TT).getArch()==Triple::x86_64' makes them *actually* identical. Can we just ditch the

After a long processing, I was able to create a version of a small C# class that was able to emulate the rproxy by P/Invoke. This is mostly to find a workaround a performance problem of the StatConnector. It's almost work but ... I have strange memory exception when I call the print function. The variable seems to not survive from one call to the other. As there is no debug symbol for