similar to: [LLVMdev] LLVM Shared DLL not supported reason

FWIW, I've got a powershell script that builds an exports.def file for recognizable C functions. You could adapt it to Python and make it part of the official build if the LLVM community thinks it will be beneficial to have libLLVM.dll The script is located here: https://github.com/mjsabby/LLVMSharp/blob/master/GenLLVMDLL.ps1 On Wed, Apr 1, 2015 at 9:03 AM, Reid Kleckner <rnk at

I'm building on Windows x64 using cmake, Ninja and VS 2013 express on Windows 7. So I have been using the LLVMSharp method on getting a usable loadable LLVM.dll[1][2]. This have worked out of the box before so it is a regression, I tracked it down to commit r250501. That commit breaks this commit, other users have also run into this specific problem[3][4]. I tried looking into the

This is also happening when using the C++ APIs. It looks like an MCJIT and SetGC interaction. I'm lost on how to proceed further. On Tue, Mar 31, 2015 at 10:42 PM, Hayden Livingston <halivingston at gmail.com> wrote: > The erlang was a typo, I was trying things out. > > I've updated the bug with a C program, which exhibits the problem. > > To answer your question,

Are you saying the textual form of IR can change, but bitcode doesn't? I don't know what you mean by assembly syntax. Is there a changlog entry when the textual IR changes? On Sat, Mar 14, 2015 at 5:22 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com> wrote: > Assembly syntax can and will break between versions. But bitcode should > generally be upgradeable, or a bug should

Thanks, David. I'd be happy to add the bindings .. is there a general way we add them? Or do you just scrub the API and make sensible judgements to the API? On Sun, Feb 1, 2015 at 1:55 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sun, Feb 1, 2015 at 10:58 AM, Hayden Livingston <halivingston at gmail.com > > wrote: > >> Hello, >> >> I

Hello, I was wondering if there is someone already working on putting the new OrcJIT APIs in the LLVM-C bindings? Also, is there a general consensus to also add C bindings when new major features are added? Hayden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150201/061f5949/attachment.html>

This is my module's dump, which is different than yours. I wonder how I can get the external thing for my function. define double @sum(double, double) { entry: call void @FooBar() %tmp = fadd double %0, %1 ret double %tmp } ; ModuleID = 'My_Module' define double @sum(double, double) { entry: call void @FooBar() %tmp = fadd double %0, %1 ret double %tmp } declare void

Thanks, Reid. I'm not an optimization expert, but as a workaround, can I do the following: void myFunction() { int local = global; .. use local ... } ? On Tue, Jun 30, 2015 at 6:53 PM, Reid Kleckner <rnk at google.com> wrote: > This came up in the past for GHC, and we recommended passing it as a > parameter everywhere, as it lets the register allocator spill it under high

Can we also codify when something should be added to the C API? For a lot of folks the C API is the only usable interface. I am one of them. We are not as vocally represented because don't generally give back to the community, usually because we are just consumers of this library. (Or maybe I'm totally wrong and lots of us give back). For example, ORC APIs in C the bindings. On Fri, Jul

Historically? I implemented support for exceptions back in LLVM 3.3, before LLVM had an implementation of a Windows unwinder. Currently? As recent as LLVM 4.0, I don't think the JIT was fully capable of handling COFF files, and LLVM wouldn't emit the correct sections (with the COFF-formatted unwind tables) when used in ELF mode. The prolog is known to be standard since Julia disables FPO

I'm trying to add gcoot functionality to my code and I'm confused by why gcroot is assuming to be an i8** I'm using i32 as object and array pointers and if I make them i8 things seem to work. I'm generating IR much like http://llvm.org/docs/GarbageCollection.html#llvm-ir-features void @llvm.gcroot(i8** %ptrloc, i8* %metadata) -------------- next part -------------- An HTML

I've just started using the llvm-pdbutil tool. Great job on the general tool. But I'm having trouble figuring out how the output of the dump tool relates to real addresses in memory or for that matter relative virtual address either. Here's the logic I tried (which doesn't work): (1) Get Instruction Pointer of interest (2) Subtract the base address of the dll that address

I'm having a problem of being unable to call into an arbitrary function that is loaded into memory whose pointer address is known to me but was not linked into LLVM. I have added the function and called LLVMAddGlobalMapping with the pointer, and the program segfaults. I was wondering if it is a supported scenario that LLVM can generate a call into an arbitrary function that is not linked.

Is it safe to assume that LLVM IR will live more-or-less the same for most releases, and that significant changes will be communicated? Or is it something that can change at any time and you must not rely on it ever being same. To me, it seems like the IR has evolved slowly but no spectacularly large changes were made in the 1-1.5 years I've been watching it, -- sure some experimental patch

On Wed, Dec 23, 2015 at 5:49 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Dec 23, 2015 at 11:29 AM, Jakob Bornecrantz via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> I'm building on Windows x64 using cmake, Ninja and VS 2013 express on Windows 7. >> >> So I have been using the LLVMSharp method on getting a usable loadable >>

Thanks for the link! There’s some code there that looks extremely relevant to say the least. > On 1 Oct 2015, at 19:00, Hayden Livingston <halivingston at gmail.com> wrote: > > Maybe looking at their code might help: > > https://github.com/dotnet/llilc/blob/dd12743f9cdb5418f1c39b2cd756da1e8396a922/lib/Jit/LLILCJit.cpp#L299 > > On Thu, Oct 1, 2015 at 10:45 AM, David

Hello, I was wondering if there is an example list somewhere of whole program optimizations done by LLVM based compilers? I'm only familiar with method-level optimizations, and I'm being told wpo can deliver many great speedups. My language is currently staticly typed JIT based and uses the JVM, and I want to move it over to LLVM so that I can have options where it can be ahead of time

Lang, aren't you going to be the major (only?) player when it comes to Orc APIs, if you're not opposed to it having them in the C bindings proper will certainly help. That's my vote, I understand it is different from the previous cases but the API surface area here is relatively small. On Mon, Sep 7, 2015 at 5:37 PM, Lang Hames <lhames at gmail.com> wrote: > Hi Jauhien, >

I was wondering if global variables can be candidates for register allocation. My use case is a global variable that is used in every function in my program. I'm wondering if it's better to pass it in, or let it stay as a global. Passing it in will require a bit of work.

Can we accept the patch which makes this work? There is a patch in the bug report for the MCJIT case. I'm confused why AOT and MCJIT case would be different but without it the information isn't registered. On Wed, Jul 6, 2016 at 9:07 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If you want an AOT linker and you don't want to use link.exe, you can use