Live data from Hacker News

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

gcc.gnu.org

1–10 of 35 posts

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

#4
post #3
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?

It looks like LLVM was designed for JIT compilation from the start.

It was. I think it's likely this effort was motivated by LLVM's relative strength in JIT compilation.

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

#5
post #3
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?

It looks like LLVM was designed for JIT compilation from the start.

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 they can't become great JIT compilers in the future, but I don't think we're there yet.

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

#6
post #3

Earlier quoted context omitted.

It looks like LLVM was designed for JIT compilation from the start.

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…

That's all relative, of course, to how long your application is going to run for and how much has to be JIT compiled.

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

#7
post #6

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…

That's all relative, of course, to how long your application is going to run for and how much has to be JIT compiled.

Sure, hence the qualifier "most of the time".

A good example of where this is important is in a tracing JIT. Do you want to compile after 1000 iterations or 10,000 iterations? Faster JIT compilation means it can kick in much earlier.

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

#8
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/master/regvm.cc...

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

#9
post #3

Earlier quoted context omitted.

It looks like LLVM was designed for JIT compilation from the start.

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.
Post reply on HN