similar to: [LLVMdev] whole program optimization examples?

With the patchpoint infrastructure, shouldn't it now be relatively straightforward to do an accurate-but-non-relocatable scan of the stack, by attaching all the GC roots as stackmap arguments to patchpoints? This is something we're currently working on for Pyston (ie we don't have it working yet), but I think we might get it "for free" once we finish the work on frame

> On Oct 13, 2014, at 4:07 PM, Philip Reames <listmail at philipreames.com> wrote: > > >> On 10/13/2014 03:23 PM, Kevin Modzelewski wrote: >> With the patchpoint infrastructure, shouldn't it now be relatively straightforward to do an accurate-but-non-relocatable scan of the stack, by attaching all the GC roots as stackmap arguments to patchpoints? This is

Thanks, Philip for the "lay of the ground" picture. I think the situation I'm in, which represents my employment (and now personal technical curiosity) is that we're seeing LLVM implementations show up like every other week or month, etc. and people are asking us, "well this mathematical software of yours is great, but my engineer here tells me it's not using this LLVM

On 10/26/13 7:40 AM, Filip Pizlo wrote: > You can implement a copying GC (what the kids these days call > relocating) without accurate roots. I use "relocating" to brush over the distinction between "copying" and "compacting" collectors. For the purposes of our discussions, the two are interchangeable though. > Why aren't you just using the well-known

On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > On 10/22/13 10:34 AM, Filip Pizlo wrote: >> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >> >>> On 10/17/13 10:39 PM, Andrew Trick wrote: >>>> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >>>> first client

On Thursday 26 February 2009 17:25:56 Chris Lattner wrote: > In my ideal world, this would be: > > 1. Subsystems [with clean interfaces] for thread management, > finalization, object model interactions, etc. > 2. Within different high-level designs (e.g. copying, mark/sweep, etc) > there can be replaceable policy components etc. > 3. A couple of actual GC implementations built

Hello, I've spent some time with the LLVM documentation and am beginning to grasp a few things, but I sometimes need very literal statements to actually understand things. My first question is about StackMaps: Is it true that llvm_gc_root_chain is an API? I've been trying to understand how exactly one accesses this structure and no where in the documentation does it mention this is a

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

On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com> wrote: > On Oct 22, 2013, at 1:48 PM, Philip R <listmail at philipreames.com> wrote: > >> On 10/22/13 10:34 AM, Filip Pizlo wrote: >>> On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: >>> >>>> On 10/17/13 10:39 PM, Andrew Trick wrote:

I'm moving this to a different thread. I think the newly proposed intrinsic definitions and their current implementation are valuable regardless of how it gets tied into GC... On Oct 22, 2013, at 6:24 PM, Philip R <listmail at philipreames.com> wrote: > Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo

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,

On Oct 22, 2013, at 9:53 AM, Philip R <listmail at philipreames.com> wrote: > On 10/17/13 10:39 PM, Andrew Trick wrote: >> This is a proposal for adding Stackmaps and Patchpoints to LLVM. The >> first client of these features is the JavaScript compiler within the >> open source WebKit project. >> > I have a couple of comments on your proposal. None of these

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

Jon Harrop wrote: > On Thursday 26 February 2009 17:25:56 Chris Lattner wrote: >> In my ideal world, this would be: >> >> 1. Subsystems [with clean interfaces] for thread management, >> finalization, object model interactions, etc. >> 2. Within different high-level designs (e.g. copying, mark/sweep, etc) >> there can be replaceable policy components etc.

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

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

Hi all, I don't know if I understand everything, but it seems really interesting for a runtime developer, stackmap and patchpoint looks perfect for a lot of optimizations :) I just have few question to verify if I understand what are these stackmaps and patchpoints, and I discuss the GC after. * I have a first very simple scenario (useful in vmkit). Let's imagine that we want to lazily

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>

Thanks, Philip. I have a sinking feeling it's not your change, but could you share the commit and so I can try it out locally? Bug: https://llvm.org/bugs/show_bug.cgi?id=23095 The reason I think it is not your change is because I tried a shared library build of LLVM 3.5.1 and that also failed with this error. Maybe it is because I'm using a package that makes an LLVM DLL for Windows.