similar to: Exception Handling Deep Dive at Dev Meeting

Hi, On Thu, 28 Jul 2016 09:32:18 -0700 Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I think David and I are probably the most familiar with how WinEH works in > LLVM, but I don't think either of us has time to prepare a talk for the dev > meeting. I'm trying to prepare a talk on supporting the MS debug info > format in LLVM this year. That said,

I think David and I are probably the most familiar with how WinEH works in LLVM, but I don't think either of us has time to prepare a talk for the dev meeting. I'm trying to prepare a talk on supporting the MS debug info format in LLVM this year. That said, I'll definitely have time to answer questions in person. It might be worth setting up a BoF to schedule some time We gave a 30m

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

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

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>

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

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

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,

It is wholly self-contained. It's code that has no references to anything beyond a set of pointers passed in as arguments to the function. This piece of code doesn't do any OS work at all. It is purely calling function pointers, doing math and allocating memory. On Mon, Jul 1, 2019 at 12:57 AM Jorg Brown <jorg.brown at gmail.com> wrote: > > Qs for you: > > The code that

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

I'm on a mission to generate code that can be loaded from disk without any modifications. This means no relocations can occur. Trying to see if this can be done for C++ code that uses STL but has no global variables, and a single function, but of course Clang will generate more functions for STL code. I want to provide an array of function pointers so that for all interactions STL needs to

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

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

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

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

I will build LLVM locally, debug and report back. On Sat, Mar 3, 2018 at 2:47 AM, Hayden Livingston <halivingston at gmail.com> wrote: > 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

On Mon, 21 May 2018, Hayden Livingston wrote: > So are you saying that LLVM can be built as ARM64 on Windows now? > CMake doesn't show me an option for ARM64 when using MSVC on Windows. > I have the latest CMake. I'm saying that LLVM can produce code for the Windows/ARM64 target. As for compiling LLVM itself to run on ARM64 on Windows, I don't know how to configure MSVC to

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.

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