Libgccjit.so: an embeddable JIT-compiler based on GCC • Hacker News Board

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#21

Post by DannyBee » Thu, Oct 03, 2013, 4:47 PM UTC

Jasper_ wrote: post #8

hartror wrote: post #2

I wonder if this would have been easier to accomplish with LLVM given that gcc's api is so notorious to deal with?

I work with David. Of course he knows about LLVM. This is his way to bring gcc into the modern era. Also related is his plan for removing global state from gcc: http://dmalcolm.fedorapeople.org/gcc/global-state/ He's seriously invested in cleaning up gcc and making it a competitive compiler. You should also see the API he has for JITing, it's much higher-level than LLVM: https://github.com/davidmalcolm/jittest/blob/m…

Could you explain what you mean by

" This is his way to bring gcc into the modern era" and "He's seriously invested in cleaning up gcc and making it a competitive compiler."

Optimization wise, GCC is still much more modern than LLVM, and in fact, more modern than a most commercial compilers.

Architecture wise, there are warts, but bringing GCC into the modern era architecturally was never a technical/engineering challenge.

To be honest, speaking as a guy who wrote plenty of GCC's current optimizations, he'd be a lot better off fixing LLVM's JIT issues than trying to rearchitect GCC.

At this point, it's hard to come up with good reasons to continue work on GCC past "fun".

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#22

Post by DannyBee » Thu, Oct 03, 2013, 4:47 PM UTC

sanxiyn wrote: post #18

jevinskie wrote: post #9

Earlier quoted context omitted.

LLVM understands this issue. That is why they have "regular" instruction selection passes and "fast" instruction selection passes. The JIT uses FastISel. But you are definitely right, it is not anywhere near as lightweight compared to, say, Hotspot.

There is also an issue of FastISel not supporting the full LLVM IR, so if you depend on FastISel for fast JIT, you basically need to design LLVM IR generation around that, limiting yourself to undocumented, unspecified, and ever changing subset of LLVM IR. Which can be done, but not very pleasant.

Right, but unlike GCC, this is not an architectural issue, but a simple implementation issue that could be fixed.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#23

Post by georgemcbay » Thu, Oct 03, 2013, 5:28 PM UTC

This is pretty cool but even when it is more robust and works with optimized code I think most developers looking for something like this are far more likely to choose LLVM for licensing reasons.

Current gcc is GPLv3 and that is very unlikely to change, if you link your project to this you are thoroughly "infected" by the GPL since unlike many GNU projects that are explicitly meant to be linked to by your own projects, gcc's core is not LGPL and the runtime library exemption granted by gcc is not sufficient to save you from infection in this use case.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#24

Post by jordigh » Thu, Oct 03, 2013, 5:29 PM UTC

This is very exciting news for GNU Octave.

One of the things in which Octave is much slower than Matlab is in looping. Matlab used to have this slowness too until they started JIT compiling their loops. For Octave, this has been more difficult, and the only tool that we've had for accomplishing this has been LLVM.

While our JIT compiler code is still very much alpha, it has already been quite a pain to deal with the LLVM JIT "API" because the truth is, they don't really have an API, i.e. no promise of stability. Every LLVM release has broken everything and our code keeps having to change in order to accomodate all of those changes. Every. Damn. LLVM. Release.

I don't know how stable the JIT API for gcc will be, but already it's starting to look much better and thought-out as a public API. Here's hoping that our fellow GNUs-in-arms can help us make a faster and better Octave!

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#25

Post by pwnna » Thu, Oct 03, 2013, 5:57 PM UTC

jordigh wrote: post #24

This is very exciting news for GNU Octave. One of the things in which Octave is much slower than Matlab is in looping. Matlab used to have this slowness too until they started JIT compiling their loops. For Octave, this has been more difficult, and the only tool that we've had for accomplishing this has been LLVM. While our JIT compiler code is still very much alpha, it has already been quite a pain to deal with the…

Yes! This will be a serious plus for Octave as it stand right now.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#26

Post by riotingpscifis » Thu, Oct 03, 2013, 6:06 PM UTC

georgemcbay wrote: post #23

This is pretty cool but even when it is more robust and works with optimized code I think most developers looking for something like this are far more likely to choose LLVM for licensing reasons. Current gcc is GPLv3 and that is very unlikely to change, if you link your project to this you are thoroughly "infected" by the GPL since unlike many GNU projects that are explicitly meant to be linked to by your own project…

Unless you are extending the compiler why would you care? GCC consistently produced faster code that LLVM

If you are extending the compiler, why would you want to allow companies like apple and oracle to bottle up you hard work and not give anything back? Either by not giving the code back or by patenting parts of the functionality they add and then suing you when you try and use them.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#27

Post by azakai » Thu, Oct 03, 2013, 6:16 PM UTC

DannyBee wrote: post #22

sanxiyn wrote: post #18

Earlier quoted context omitted.

There is also an issue of FastISel not supporting the full LLVM IR, so if you depend on FastISel for fast JIT, you basically need to design LLVM IR generation around that, limiting yourself to undocumented, unspecified, and ever changing subset of LLVM IR. Which can be done, but not very pleasant.

Right, but unlike GCC, this is not an architectural issue, but a simple implementation issue that could be fixed.

It's an implementation issue, but it is far from simple.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#28

Post by [deleted] » Thu, Oct 03, 2013, 6:36 PM UTC

DannyBee wrote: post #21

Jasper_ wrote: post #8

Earlier quoted context omitted.

I work with David. Of course he knows about LLVM. This is his way to bring gcc into the modern era. Also related is his plan for removing global state from gcc: http://dmalcolm.fedorapeople.org/gcc/global-state/ He's seriously invested in cleaning up gcc and making it a competitive compiler. You should also see the API he has for JITing, it's much higher-level than LLVM: https://github.com/davidmalcolm/jittest/blob/m…

Could you explain what you mean by " This is his way to bring gcc into the modern era" and "He's seriously invested in cleaning up gcc and making it a competitive compiler." Optimization wise, GCC is still much more modern than LLVM, and in fact, more modern than a most commercial compilers. Architecture wise, there are warts, but bringing GCC into the modern era architecturally was never a technical/engineering chal…

[deleted]

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#29

Post by ahomescu1 » Thu, Oct 03, 2013, 7:49 PM UTC

jevinskie wrote: post #9

DanWaterworth wrote: post #5

Earlier quoted context omitted.

LLVM doesn't make a great JIT compiler and I don't think gcc will either. The problem is that, most of the time, your JITed code won't be used very much and so the amount of time that it takes to generate it is a significant proportion of the total execution time. LLVM and gcc are optimized for producing the fastest possible code and will do so at the expense of spending more time doing it. That's not to say that the…

LLVM understands this issue. That is why they have "regular" instruction selection passes and "fast" instruction selection passes. The JIT uses FastISel. But you are definitely right, it is not anywhere near as lightweight compared to, say, Hotspot.

The JIT doesn't always use FastISel. Last time I checked, you had to enable it manually, or set optimization to -O0.

Re: Libgccjit.so: an embeddable JIT-compiler based on GCC

#30

Post by MichaelGG » Thu, Oct 03, 2013, 8:02 PM UTC

riotingpscifis wrote: post #26

georgemcbay wrote: post #23

This is pretty cool but even when it is more robust and works with optimized code I think most developers looking for something like this are far more likely to choose LLVM for licensing reasons. Current gcc is GPLv3 and that is very unlikely to change, if you link your project to this you are thoroughly "infected" by the GPL since unlike many GNU projects that are explicitly meant to be linked to by your own project…

Unless you are extending the compiler why would you care? GCC consistently produced faster code that LLVM If you are extending the compiler, why would you want to allow companies like apple and oracle to bottle up you hard work and not give anything back? Either by not giving the code back or by patenting parts of the functionality they add and then suing you when you try and use them.

It's not LGPL, so linking to it means your entire project is now GPLv3.