search for: pystone

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

The only VHDL to LLVM project that I know of is nvc. [0] I haven't tried it personally and from a cursory look through the source it seems like there is a LLVM backend and a "native" backend (not sure what that means). If you're really crazy you might want to see if you could massage GHDL [1] (VHDL GCC frontend) + DragonEgg [2] (LLVM backend for GCC) to get you LLVM IR. I'm

Hello all, I'm trying to hack MCJIT::emitObject to optionally output the corresponding text assembly associated with the object code being emitted (if a debug flag is set in the app/dev environment which is hosting LLVM). I attempted to do this by adding another AsmPrinter pass to the PassManager, but this runs into all sorts of problems because there's only once MCContext and one

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

LLVM Weekly - #126, May 30th 2016 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/126>. Welcome to the one hundred and twenty-sixth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

I don't believe the changes have made it in yet. In addition to the previous patch set, we've got an independent implementation we've been using for a while: https://github.com/AzulSystems/llvm-late-safepoint-placement We really should get one or the other merged in tree. Could you point me to the previous patch set so I can ping it and review? Philip -------- Original Message

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

...e controllers (requires tw_cli) harddisks - information (firmware, model, make) for non-3ware controllers. These 2 are especially nice for those people who might have seagate harddisks in their boxes... raid - more information than in: http://reductivelabs.com/trac/puppet/wiki/Recipes/RaidFact pystone - makes a simple pystone python benchmark and averages on it (gives you some hints about the processor speed) bogomips - yes, they are funny. macosx_productcode - Leopard,Tiger,Panther et al classes - in which classes is this host? graphics - nvidia,ati or false ( :( ) ssetype - sse or sse2 - thi...

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

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 Kevin, To elaborate on Philip's point, depending on the state Pyston's runtime already is in, you may have the choice of using a hybrid of a "pending exception" word in your runtime thread structure, and an implicit alternate ("exceptional") return address for calls into functions that may throw. This lets you elide the check on the pending exception word after

I think what's happening is BranchFolder::MaintainLiveIns is using a forward analysis on top of these missing kill flags, and updating the BB-live-ins/live-outs with an incorrect set of registers. Then when the stackmaps liveness analysis happens, it's not doing anything wrong, but it starts with the wrong set of live registers and will propagate those to the point of the

Thanks, happy to of confirmed. With that in mind, will use the AST modules provided by the languages (with the exception of libclang for C++). Antoine: Am aware of Numba, nice job there BTW. So is there a [decoupled] LLVM parser which I can use to read Python files and analyse objects (including computing their attributes in OO and setattr scenarios)? On Wed, Jul 1, 2015 at 10:23 PM, Antoine

On 09/08/2014 04:22 PM, Dan Gohman wrote: > An object can be allocated at virtual address 5 through extra-VM means > (eg. mmap), and then one can (creatively) interpret the return value > of @f as being associated with whatever %A was associated with *and* > 5. The return value of @g can only be associated with exactly the same > set that %A was associated with. Consequently,

Sounds good. I will add that to the StackMap documentation when I update it for v2. —Juergen > On Jul 10, 2015, at 9:40 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > No, but I've noticed that it is true in practice, and so I think that we should say something about it one way or another. Especially since, in switching to a fixed-size record format, binary searching now

> 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

Dear All I have some questions about how to use patchpoint intrinsic: 1- The function that is provided as argument to the intrinsic call, where does it belong? I'm making a pass to change a given IR file and add call to patchpoint. Where should I put this function? In the pass or in the same IR file or in another IR and include it or what? 2- When actually this code is patched into the

Hi all, I'm organizing a BoF session during the upcoming EuroLLVM developers meeting. As the subject of this message already shows, this session will be on compilers in education. I'm currently looking for both participants to the discussion and input for the actual program of the session. I've already got some ideas which I'll introduce below. At our university, we mostly

...ranslated with the rest of PyPy. This makes using the translated pypy interactively much more pleasant, as compilation is considerably faster than in 0.7.0. - Some Speed enhancements. Translated PyPy is now about 10 times faster than 0.7 but still 10-20 times slower than CPython on pystones and other benchmarks. At the same time, language compliancy has been slightly increased compared to 0.7 which had already reached major CPython compliancy goals. - Some experimental features are now translateable. Since 0.6.0, PyPy shipped with an experimental Object Space (the part of...

This is a follow up on a conversation some of us had at the hacker lab -- I noticed that sometimes I will get notified that a deopt value lives in a register that is not callee-save (caller-save I guess, but is there another term for this that is less similar to callee-save?). This surprised me quite a bit since those registers immediately got clobbered by the call inside the patchpoint, so we