similar to: [LLVMdev] [llvm-c] Proposal: Make LLVMInitializeNativeTarget and co. non-inline

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> ...

Dear LLVM devs (and other subscribers), when building llvm as a shared library (so or dll, tested with both) and then performing objdump on the resulting library will reveal that LLVMInitializeNativeTarget does not get exported ("objdump -x libLLVM-3.3svn.so | grep LLVMInitializeNativeTarget" will return without any output). As far as I can tell this is because the function is

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

So, I'm setting about trying to fix the layering of TargetSelect.h (& TargetRegistry.h, but haven't really got to its issues yet). The issues can be demonstrated fairly plainly by moving any/all of TargetSelect.h's functions out of line. Pretty much all programs in LLVM fail to link because libSupport doesn't actually depend on all the targets, quite the opposite in fact. So,

I've managed to get 10.0.0 working now.. there were a couple things I had to adjust. The Kaleidoscope example had me doing this before creating the object file: llvm::InitializeAllTargetInfos(); llvm::InitializeAllTargets(); llvm::InitializeAllTargetMCs(); llvm::InitializeAllAsmParsers(); llvm::InitializeAllAsmPrinters(); It turns out I can get away with just this, since I'm not (yet)

Hello, a few days ago, I was trying to access the LLVM target registry via the LLVM-C interface. Unfortunately I can't seem to get some useful information out of it. Despite the fact that the following code is written in Pascal, can you please tell me if I have done something wrong here? // initialize all targets / target information LLVMInitializeAllTargets; LLVMInitializeAllTargetInfos;

Hi all, I have some code that uses the x86 JIT via the C bindings that I'm trying to migrate from targeting LLVM 2.5 to the top of tree, but I'm running into a linking problem I can't figure out. Here's how I'm invoking the JIT in 2.5. LLVMInitializeNativeTarget(); <-- for the updated version LLVMCreateMemoryBufferWithContentsOfFile("code.bc", &buffer,

llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a

I've been struggling to get LLVM to work from .NET using the llvm-fs bindings for the past few weeks. I finally found an installation procedure that works and documented it here: http://fsharpnews.blogspot.com/2012/03/using-llvm-from-f-under-windows.html The good news is that I have that program compiling the Fibonacci function and executing it from F# all via LLVM. However, I still have a

Oops, missed initializing some stuff. Added: LLVMLinkInMCJIT(); LLVMInitializeNativeTarget(); LLVMInitializeNativeAsmPrinter(); LLVMInitializeNativeAsmParser(); Now it crashes in LLVMGetFunctionAddress(). Hmm. On Wed, Mar 8, 2017 at 5:14 PM, Toshiyasu Morita <toshi at tensyr.com> wrote: > Made it a bit further. Here's the current code: > >

On Sat, May 11, 2013 at 01:48:44PM +0200, Christian Budde wrote: > Hello, > > a few days ago, I was trying to access the LLVM target registry via the > LLVM-C interface. Unfortunately I can't seem to get some useful > information out of it. > > Despite the fact that the following code is written in Pascal, can you > please tell me if I have done something wrong here?

Am 13.05.2013 16:16, schrieb Tom Stellard: > On Sat, May 11, 2013 at 01:48:44PM +0200, Christian Budde wrote: >> Hello, >> >> a few days ago, I was trying to access the LLVM target registry via the >> LLVM-C interface. Unfortunately I can't seem to get some useful >> information out of it. >> >> Despite the fact that the following code is written in

There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). To generate PTX at run-time, you just set up a standard codegen pass manager like you would like an off-line compiler. The output will be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

Ah, that's helpful. I knew that I'd need to end up with PTX as text, not a true binary, but I would have figured that it would come out of MCJIT. Thanks for helping to steer me away from the wrong trail. OK, one more question: Can anybody clarify the pros and cons of generating the PTX through the standard LLVM distro, versus using the "libnvvm" that comes with the Cuda SDK?

Kenneth Uildriks wrote: > 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 >

Hello, [Using LLVM r155315, according to `svn log | head`] I am experimenting with programatically building and jitting functions in a module, and I seem to be coming across a crash in some generated code. Using the llvm-c interface I build up the module which dumps like this: ; ModuleID = 'MyModule' target datalayout = "i686-apple-darwin11" target triple =

When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function

Hi, I wrote a compiler that generate IR code and run it on the JIT, and there randomly crashed due to "corrupted size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession

Hi, I am trying to implement a scenario similar to running ExceptionDemo.cpp with parameter -1 (where the JITed code calls the C++ function which throws an exception) Different from the given example I am using IRParser instead of IRBuilder. I can successfully catch the exception in Linux but the program crashes in Mac and Windows. The code is similar to as follows: ### The test.cpp :