search for: modzelewski

On 12/18/2014 06:58 PM, Kevin Modzelewski wrote: > I'd be interested in that, though would it be an issue if it doesn't > have an in-tree user? Quite possibly. It would bit rot if nothing else. At minimum, we need a dumper tool - possibly an option to an existing one - which produces human readable output and a bunch of l...

Yeah, that's probably how I'd do it. Might be useful if you guys want to contribute that as a command line option Kevin. -eric On Tue, Jun 24, 2014 at 3:03 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > We do this in Pyston using a JITEventListener that just disassembles the > output; it's "it works let's move on"-quality: > https://github.com/dropbox/pyston/blob/master/src/codegen/dis.cpp > > I'm not sure how efficient the...

...e sure that the liveness information was accurate when the stackmaps code looks at it, wouldn't we need to get rid of anything that supports forward liveness analysis? On Mon, Oct 13, 2014 at 8:27 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 13, 2014, at 5:45 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > > Hi all, I've run into a couple bugs recently that affected stackmap > liveness analysis in various ways: > http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live > unnecessarily > http://llvm.org/bugs/show_bug.cgi?id=21...

The pass manager is re-created in emitObject on every call. Andy, is that needed or can we create the PM in MCJIT constructor and keep it around? Yaron 2013/11/19 Kevin Modzelewski <kmod at dropbox.com> > So I finally took the plunge and switched to MCJIT (wasn't too bad, as > long as you remember to call InitializeNativeTargetDisassembler if you want > disassembly...), and I got the functionality to a point I was happy with so > I wanted to test perf o...

Hi all, I'm trying to reduce the startup time for my JIT, but I'm running into the problem that the majority of the time is spent loading the bitcode for my standard library, and I suspect it's due to debug info. My stdlib is currently about 2kloc in a number of C++ files; I compile them with clang -g -emit-llvm, then link them together with llvm-link, call opt -O3 on it, and arrive

...debug build. > > Rafael, am I remembering this right/can you give more information? I > expect that this will have to get fixed before pitching LLD as a turnkey > LTO solution (not sure where in the priority list it is). > > -- Sean Silva > On Thu, Jan 9, 2014 at 5:37 PM, Kevin Modzelewski <kmod at dropbox.com>wrote: > > Hi all, I'm trying to reduce the startup time for my JIT, but I'm running > into the problem that the majority of the time is spent loading the bitcode > for my standard library, and I suspect it's due to debug info. My stdlib > is c...

Hi all, I'm working on implementing exceptions in Pyston, and I was hoping to get some guidance from the list. I think I've learned enough about C++-style DWARF exceptions to convince myself I have a workable approach, but then I found this VMKit paper (2010) which says The exception manager: To manage exceptions, J3 reserves a > word for the pending exception in the local storage of

So I finally took the plunge and switched to MCJIT (wasn't too bad, as long as you remember to call InitializeNativeTargetDisassembler if you want disassembly...), and I got the functionality to a point I was happy with so I wanted to test perf of the system. I created a simple benchmark and I'd thought I'd share the results, both because I know I personally had no idea what the

Hi all, Our use case for LLVM requires us to parse the .eh_frame sections emitted by MCJIT (for callee-saved-register spill slots, amongst other things). Does it make sense to have an in-tree parser for .eh_frame, given that it will make such tasks a lot easier? -- Sanjoy

...mbering this right/can you give more information? I >>> expect that this will have to get fixed before pitching LLD as a turnkey >>> LTO solution (not sure where in the priority list it is). >>> >>> -- Sean Silva >>> On Thu, Jan 9, 2014 at 5:37 PM, Kevin Modzelewski <kmod at dropbox.com>wrote: >>> >>> Hi all, I'm trying to reduce the startup time for my JIT, but I'm >>> running into the problem that the majority of the time is spent loading the >>> bitcode for my standard library, and I suspect it's due to...

...t require that the two copies of the Test class > template appear on the same line in the same file in two distinct > translation units, it only requires that the two copies have the same > sequence of tokens - which they do in your example) > > On Fri, Jun 13, 2014 at 5:33 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: >> Hi all, sorry to post to both lists, but I'm running into an issue where >> clang-generated debug info is deemed to be invalid by LLVM tools (throws an >> assertion error in both llc and mcjit), and I'm not sure what the proper >&gt...

Hi all, sorry to post to both lists, but I'm running into an issue where clang-generated debug info is deemed to be invalid by LLVM tools (throws an assertion error in both llc and mcjit), and I'm not sure what the proper resolution is. Here's a test case; I last tested it on revision r210953: $ cat test1.cpp #include "test.h" test::Test<int> foo1() { return

> 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 something we're currently working on for Pyston (ie we don...

On Dec 9, 2013, at 3:59 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: > About lazy compilation, I'm still of the opinion that that's better handled > outside of MCJIT. For the people asking for it, would it be enough to have > a wrapper around MCJIT that automatically splits modules and adds stubs to > do lazy...

...pear on the same line in the same file in two distinct >>>>> translation units, it only requires that the two copies have the same >>>>> sequence of tokens - which they do in your example) >>>>> >>>>> On Fri, Jun 13, 2014 at 5:33 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: >>>>>> Hi all, sorry to post to both lists, but I'm running into an issue where >>>>>> clang-generated debug info is deemed to be invalid by LLVM tools (throws an >>>>>> assertion error in both llc and mcji...

Yep we have our own parser <https://github.com/vinzenz/libpypa/> and we would love to see other people use it. When we looked around at some other Python parsers we didn't feel like any of them were easy to extract and use on their own, so we wrote our own and I think were able to keep ours well-separated. There are some things that make parsing Python somewhat difficult to do in a

Hi all, I've run into a couple bugs recently that affected stackmap liveness analysis in various ways: http://llvm.org/bugs/show_bug.cgi?id=19224 - function arguments stay live unnecessarily http://llvm.org/bugs/show_bug.cgi?id=21265 - eflags can end up as a live out http://llvm.org/bugs/show_bug.cgi?id=21266 - %rip can end up as a live out The first two have nothing to do with stackmaps

...t class >>> template appear on the same line in the same file in two distinct >>> translation units, it only requires that the two copies have the same >>> sequence of tokens - which they do in your example) >>> >>> On Fri, Jun 13, 2014 at 5:33 PM, Kevin Modzelewski <kmod at dropbox.com> wrote: >>>> Hi all, sorry to post to both lists, but I'm running into an issue where >>>> clang-generated debug info is deemed to be invalid by LLVM tools (throws an >>>> assertion error in both llc and mcjit), and I'm not sure...

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

A high level summary of the proposal as it stands right now (from my perspective), after incorporating Philip's suggestions: 1. Operand bundles are a way to associate a set of SSA values with a call or invoke. 2. Operand bundles are lowered in some arbitrary bundle-tag specific manner. 3. The optimizer can optimize around operand bundles with (roughly) the assumption that