Adding JIT-compilation to a toy interpreter
gcc.gnu.org
Adding JIT-compilation to a toy interpreter
1–10 of 15 posts
Re: Adding JIT-compilation to a toy interpreter
#2-march=native to the people! BTW, does anyone know whether the jvm compiles java code with processor-specific instructions i.e. beyond the common denominator amd64?
Re: Adding JIT-compilation to a toy interpreter
#3-march=native to the people! BTW, does anyone know whether the jvm compiles java code with processor-specific instructions i.e. beyond the common denominator amd64?
[deleted]
Re: Adding JIT-compilation to a toy interpreter
#4So, while interesting work, and certainly an accomplishment i have a couple problems with this (and i know it's alpha and not supposed to be used in production, blah blah blah).
First and foremost, the language reference is not a language reference: https://gcc.gnu.org/onlinedocs/jit/
It tries to define operations by saying "it's analogous to C". But that's not an actual thing. Either it's C or it's not C. If it's C, what language level is it?
Does it actually have the same semantics as C? (The answer, from what I can tell, is no, it has the semantics of GIMPLE, which is to say, 'random stuff unless you set flags on DECL's, etc')
I could go on, but i would have much rather seen someone sit down, think about what the JIT semantics were supposed to be, and build that, rather than take GCC, and build a JIT out of whatever pieces happened to be laying around :)
For those who think is a lot of work, this is generally the right way around to do it. You build the IR, then the compiler (or start building the IR, then the compiler, and refine the IR as you discover you f'd it up).
2. It has no real optimization pipeline management. About all you can manage is the GCC options (both internal and external).
This is pretty bad. Again, normally you would start with a simple pass manager, etc.
3. From what i can tell, it only targets whatever arch you have compiled GCC for in this case, which is usually "1".
To be frank (with no disrespect to it's author meant!), compared to something like LLVM's JIT, this is at least 4-5 years of serious engineering work behind (this includes all the work to do things like "define the semantics of the IR", etc).
Again, to be frank, considering the alternatives, i have trouble seeing why anyone would want to use this unless they were a serious free software advocate.
It reminds me of the old joke about cygwin - the power of windows, the interface of unix.
Re: Adding JIT-compilation to a toy interpreter
#5So, while interesting work, and certainly an accomplishment i have a couple problems with this (and i know it's alpha and not supposed to be used in production, blah blah blah). First and foremost, the language reference is not a language reference: https://gcc.gnu.org/onlinedocs/jit/ It tries to define operations by saying "it's analogous to C". But that's not an actual thing. Either it's C or it's not C. If it's C,…
Does it support all of GCC's targets? That'd be another reason to use it.
Re: Adding JIT-compilation to a toy interpreter
#6-march=native to the people! BTW, does anyone know whether the jvm compiles java code with processor-specific instructions i.e. beyond the common denominator amd64?
Yes. For example, the hotspot VM can make use of AVX and AVX2 instructions if supported by the CPU.
http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee275...
Re: Adding JIT-compilation to a toy interpreter
#7So, while interesting work, and certainly an accomplishment i have a couple problems with this (and i know it's alpha and not supposed to be used in production, blah blah blah). First and foremost, the language reference is not a language reference: https://gcc.gnu.org/onlinedocs/jit/ It tries to define operations by saying "it's analogous to C". But that's not an actual thing. Either it's C or it's not C. If it's C,…
Does it support all of GCC's targets? That'd be another reason to use it.
Not really.
But this isn't about the JIT, GCC doesn't support all of GCC's targets, and rightfully so. They couldn't if they wanted to :)
They have some primary and secondary platforms: https://gcc.gnu.org/gcc-4.9/criteria.html
Primary platforms are what you care about. It means they won't do a release if these have regressed.
The primary platforms are the usual suspects (and LLVM has backends for all of them).
The secondary platforms are mildly interesting. LLVM has backends for those, too. In GCC land, only the majority of tests have to pass for a release for the secondary platforms.
The secondary platforms only have two arches over the primary ones:
s390 aarch64
This is a really long way of saying: I don't think it works on all targets, i don't think it will ever work on all targets, and i wouldn't use it expecting it does. If you stick to the supported platforms, you aren't buying anything over the alternatives. If you don't stick to the supported platforms, why start with GCC, when they aren't going to support it?
Re: Adding JIT-compilation to a toy interpreter
#8So, while interesting work, and certainly an accomplishment i have a couple problems with this (and i know it's alpha and not supposed to be used in production, blah blah blah). First and foremost, the language reference is not a language reference: https://gcc.gnu.org/onlinedocs/jit/ It tries to define operations by saying "it's analogous to C". But that's not an actual thing. Either it's C or it's not C. If it's C,…
Where does it claim to be a language reference? I only see it referred to as an API. It seems like you are evaluating it in terms of how LLVM does things, which is maybe the wrong way to look at it. It's a library, not an IR.
Re: Adding JIT-compilation to a toy interpreter
#9So, while interesting work, and certainly an accomplishment i have a couple problems with this (and i know it's alpha and not supposed to be used in production, blah blah blah). First and foremost, the language reference is not a language reference: https://gcc.gnu.org/onlinedocs/jit/ It tries to define operations by saying "it's analogous to C". But that's not an actual thing. Either it's C or it's not C. If it's C,…
I'm curious, what motivated you to put so much effort into criticizing a clearly marked toy designed as an demonstration of basic techniques?
Re: Adding JIT-compilation to a toy interpreter
#10So, while interesting work, and certainly an accomplishment i have a couple problems with this (and i know it's alpha and not supposed to be used in production, blah blah blah). First and foremost, the language reference is not a language reference: https://gcc.gnu.org/onlinedocs/jit/ It tries to define operations by saying "it's analogous to C". But that's not an actual thing. Either it's C or it's not C. If it's C,…
I'm curious, what motivated you to put so much effort into criticizing a clearly marked toy designed as an demonstration of basic techniques?
????
I think you are confused. I'm criticizing the JIT library, not the toy example.
http://developerblog.redhat.com/2015/04/07/jit-compilation-u...
"As the author, I may be biased, but I believe libgccjit makes it relatively easy to build a compiler"
I think this is flat out wrong :)