From: Mike M. <cr...@gm...> - 2013-02-26 07:30:57
Attachments:
signature.asc
|
Dear hackers, I knew that this mail may offend some hackers, but I still want to post this. Sorry :-( LLVM is now a great platform for interpreted languages as well as static languages. LLVM provides us with a high-speed JIT and interpreter (lli), a compiler and a linker. That is, if we make an LLVM backend, we get all of these at once. SBCL's original code generator doesn't have a JIT for bytecode (if we don't want to publish the code), LLVM can provides us. Also, if you guys want, we can also create a REAL executable file (quite easy with the power of LLVM). This might be a huge project, however, when it's done, advantages are much more than disadvantages. Compared with doing them all by ourselves, the project seems easier though. -- ===========道可道也=========== | Mike Manilone (ekd123) | | http://www.ekd123.org | ===========非恆道也=========== |
From: John L. <cod...@in...> - 2013-02-26 07:55:50
|
On Tue, Feb 26, 2013 at 03:15:26PM +0800, Mike Manilone wrote: > > LLVM is now a great platform for interpreted languages as well as static > languages. LLVM provides us with a high-speed JIT and interpreter (lli), > a compiler and a linker. That is, if we make an LLVM backend, we get all > of these at once. Yes, but on only a small subset of the platforms SBCL currently supports? > This might be a huge project, however, when it's done, advantages are > much more than disadvantages. Compared with doing them all by ourselves, > the project seems easier though. Are you going to maintain the code generators for platforms LLVM doesn't support, or is SBCL only going to run on what LLVM supports? -- ASCII ribbon campaign ( ) Powered by Lemote Fuloong against HTML e-mail X Loongson MIPS and OpenBSD and proprietary / \ http://www.mutt.org attachments / \ Code Blue or Go Home! Encrypted email preferred PGP Key 2048R/DA65BC04 |
From: Mike M. <cr...@gm...> - 2013-02-26 08:13:37
Attachments:
signature.asc
|
在 2013-02-26二的 07:54 +0000,John Long写道: > On Tue, Feb 26, 2013 at 03:15:26PM +0800, Mike Manilone wrote: > > > > LLVM is now a great platform for interpreted languages as well as static > > languages. LLVM provides us with a high-speed JIT and interpreter (lli), > > a compiler and a linker. That is, if we make an LLVM backend, we get all > > of these at once. > > Yes, but on only a small subset of the platforms SBCL currently supports? > > > This might be a huge project, however, when it's done, advantages are > > much more than disadvantages. Compared with doing them all by ourselves, > > the project seems easier though. > > Are you going to maintain the code generators for platforms LLVM doesn't > support, or is SBCL only going to run on what LLVM supports? > The original code generator could be kept as usual :-P Users could choose which one they like (being a compiling option) -- ===========道可道也=========== | Mike Manilone (ekd123) | | http://www.ekd123.org | ===========非恆道也=========== |
From: David L. <da...@li...> - 2013-02-26 08:26:55
|
Quoting Mike Manilone (cr...@gm...): > I knew that this mail may offend some hackers, but I still want to post > this. Sorry :-( Personally I see no reason why it would -- the possibility of an LLVM backend has been discussed a couple of times, and the only reason I'm aware of that it hasn't been done is lack of time. Mind you, there are a couple of technical issues that need to be resolved before such a backend would work perfectly. But none of these should prevent anyone from getting started. [...] > Also, if you guys want, we can also create a REAL executable file (quite > easy with the power of LLVM). In fact, the code generated in this case is (or was, the last time I checked) much more compact than the code generated by the JIT. I would suggest re-linking from bytecode into a binary whenever the core gets dumped, and JIT only newly-defined functions. > This might be a huge project, however, when it's done, advantages are > much more than disadvantages. Compared with doing them all by ourselves, > the project seems easier though. "We're taking patches." [1] d. ---- [1] Saying this with apologies to Dmitry and Anton. |
From: Martin C. <cra...@co...> - 2013-02-26 15:06:05
|
Mike Manilone wrote on Tue, Feb 26, 2013 at 03:15:26PM +0800: > Dear hackers, > > I knew that this mail may offend some hackers, but I still want to post > this. Sorry :-( > > LLVM is now a great platform for interpreted languages as well as static > languages. LLVM provides us with a high-speed JIT and interpreter (lli), > a compiler and a linker. That is, if we make an LLVM backend, we get all > of these at once. Yupp. That idea has been floating around for a while. James Knight hacked up a beginning of it during the SBCL meeting in London: https://groups.google.com/forum/?fromgroups=#!topic/sbcl-devel/Mg3hKr5l9Ww We would be highly interested if this project could be pushed at least to a level where functions of significant size were running (not all features of CL supported) so that it would become clear how much performance we drop on the floor here. I did some tinkering reproducing the most braindead assembly sequence I could find SBCL generate in regular assembly and benchmarked it against better versions. Modern CPUs have good ability to blast through some braindead assembly as long as it doesn't touch memory. Noodling around with a couple instructions more on the same registers is done quickly by modern processors. So I don't take it as a give that a LLVM backend would be an earth-shaking speed improvement. Having said that, some performance problems are wedgelocked in the current backends, e.g. an unwind-protect that is slow even when no exception happens (whereas gcc has exceptions that are free unless thrown). Maybe a new backend written while keeping this in mind wouldn't end up there. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cra...@co...> http://www.cons.org/cracauer/ |
From: Elliott S. <ell...@gm...> - 2013-02-26 17:51:51
|
On Mon, Feb 25, 2013 at 11:15 PM, Mike Manilone <cr...@gm...> wrote: > Dear hackers, > > LLVM is now a great platform for interpreted languages as well as static > languages. LLVM provides us with a high-speed JIT and interpreter (lli), > a compiler and a linker. That is, if we make an LLVM backend, we get all > of these at once. > I would note that writing an efficient GC in LLVM is not such an easy thing to do, especially if you want it to be precise-on-the-stack. I gave a talk about this after spending a summer trying (and mostly failing) to do the same for Rust[1]. LLVM's existing "GC support" works only when all pointers are permanently rooted on the stack, and prevents LLVM from ever moving pointers into registers. There are hacks to work around this, but they're all pretty awful. That said, if you're happy with conservative-on-the-stack GC, then maybe this won't matter to you. At any rate, it looks like the only realistic option for Rust at this point. I'd be happy to discuss this more if anyone is interested. [1]: https://github.com/elliottslaughter/rust-gc-talk [2]: http://llvm.org/docs/GarbageCollection.html -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |
From: Paul K. <pv...@pv...> - 2013-02-26 22:03:19
|
Elliott Slaughter wrote: > I would note that writing an efficient GC in LLVM is not such an easy > thing to do, especially if you want it to be precise-on-the-stack. I > gave a talk about this after spending a summer trying (and mostly > failing) to do the same for Rust[1]. LLVM's existing "GC support" works > only when all pointers are permanently rooted on the stack, and prevents > LLVM from ever moving pointers into registers. There are hacks to work > around this, but they're all pretty awful. Right, the usual via-C tricks… SBCL's already conservative wrt the stack and registers, on x86[-64] and on threaded PPC; however, it assumes that there are no derived/interior pointers, or, at least, that they're backed by a tagged pointer that remains live (on stack, or in a register). Is it at least possible to disable optimisations that would CSE/hoist pointer arithmetic away or perform the address arithmetic in place, leaving only an untagged or, worse, an interior pointer? IIRC, this is very similar to the kind of guarantees BDW needs, so hopefully there's some support for these constraints. Paul Khuong |
From: Elliott S. <ell...@gm...> - 2013-03-02 04:06:29
|
On Tue, Feb 26, 2013 at 2:02 PM, Paul Khuong <pv...@pv...> wrote: > Elliott Slaughter wrote: > >> I would note that writing an efficient GC in LLVM is not such an easy >> thing to do, especially if you want it to be precise-on-the-stack. I >> gave a talk about this after spending a summer trying (and mostly >> failing) to do the same for Rust[1]. LLVM's existing "GC support" works >> only when all pointers are permanently rooted on the stack, and prevents >> LLVM from ever moving pointers into registers. There are hacks to work >> around this, but they're all pretty awful. >> > > Right, the usual via-C tricks… > > SBCL's already conservative wrt the stack and registers, on x86[-64] and > on threaded PPC; however, it assumes that there are no derived/interior > pointers, or, at least, that they're backed by a tagged pointer that > remains live (on stack, or in a register). Is it at least possible to > disable optimisations that would CSE/hoist pointer arithmetic away or > perform the address arithmetic in place, leaving only an untagged or, > worse, an interior pointer? IIRC, this is very similar to the kind of > guarantees BDW needs, so hopefully there's some support for these > constraints. > At the level of the machine independent LLVM IR, you have fairly fine-grained control over optimization selection and order. You can easily avoid optimizations that are problematic and replace them with custom versions which maintain any invariants you care about. This part of LLVM also happens to be reasonably stable and well documented, so I think someone experienced in compiler development but new to LLVM could come in and get up to speed pretty quickly. Below that, at the level of LLVM's machine-specific backends, the situation is less pleasant. This part of LLVM is less stable and less well documented; at the time I was working on this the documentation basically amounted to a blog post explaining the overall architecture, and the code itself. The machine backends are less restrictive on what they can do to registers, so you can't really know what's in a register after the code passes through all the optimizations. The only saving grace at this layer is that (I believe) the backends won't optimize across basic blocks, so things can only travel so far. If you want to be safe at this level the most straightforward way to do it is to copy LLVM's GC support and make sure you keep copies of all the roots on the stack. Other alternatives require custom modifications to the LLVM backends, which are challenging at best and untenable at worst. I think a conservative GC should be entirely doable, the only question is how the performance will be at the end. To start out, you could just use LLVM's existing GC support, and worry about performance after you're past the initial hurdle of making it work at all. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay |