Comment by DannyBee | Hacker News Reader

Comment by DannyBee | Hacker News Reader

Parent Full thread

So, 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.

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?

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.

I strongly disagree.

It claims to have types, etc. It doesn't say "these are GCC types, see the GCC docs". It says "here are some types, they act kinda like C".

It's certainly a library, but that's not relevant.

It has it's own expressions, lvalues, rvalues, Something, somewhere, needs to describe the semantics of these operations.

The JIT docs at https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html, again, don't say "this is identical to GCC's NEGATE_EXPR" or whatever, they say:

"GCC_JIT_UNARY_OP_MINUS Negate an arithmetic value; analogous to:

-(EXPR) in C."

IE It defines it's own UNARY_MINUS operator, not "GCC's" (GCC is NEGATE_EXPR).

It then tells you nothing about what it actually does (because it's only analogous to some random version of C).

If it said "this has the semantics of GCC's NEGATE_EXPR", that might be something (but the semantics of GCC's operations are not well defined either :P)

A lot of JIT's are programming language specific, and so they have it easy. They just define their operations/results/etc in terms of the programing language they are a JIT for.

But they are not attempting to do that here. They are attempting to present it as a JIT for "whatever you want". But you couldn't actually use this to produce a JIT for a language and know how the end result will act when you produce certain JIT operations with what they have given you. That is a pretty basic requirement for using a JIT, library or not :)

In short, again, i think this is built the wrong way around. Building a Jit for a bunch of not-well-defined operations doesn't give anyone anything interesting.

Would you still object if the tables had the heading 'ANSI C Equivalent', for example, instead of 'C Equivalent'? They are clearly defined relative to C, so is your problem with the lack of explicit version? Or do you object to C as an IR?

Personally, I actually quite like the idea of C as an IR.

"They are clearly defined relative to C"

The author doesn't claim this (it's why he says analagous), and in fact, they aren't.

You don't have to believe me, try it! (or read the source: gcc/gcc/jit/jit-playback.c)

I don't think you will find they have ANSI C89/C99/etc semantics. Because they don't. It's not parsing C or generating C, or reusing part of the c GIMPLE generation, it's creating GIMPLE from whole cloth. Thus, you will find they have "GIMPLE" semantics. This is because they are defined relative to GIMPLE, which is "defined" to be kinda like C but not really. In fact, it has no well defined semantics. Which causes all sorts of issues.

"Personally, I actually quite like the idea of C as an IR."

This is why GIMPLE exists, of course. It's just not well defined on it's own, without the presence of a frontend (we call the things it requires "langhooks" because it still needs to ask the language frontend to do things). The reason it can compile C accurately is because the c-frontend and the GIMPLE lowering passes it uses

A. Know how generate correct GIMPLE for C89/99/11

B. Set about 100 different types of flags on various expressions that the rest of the middle-end/backend understand what to do with.

C. Have langhooks so the middle end can do the rest.

The JIT does not do this. and langhooks are everwhere

This is true even in simple cases, like creation of string literals, for which it does:

  /* Convert to (const char*), loosely based on
     c/c-typeck.c: array_to_pointer_conversion,
     by taking address of start of string.  */
  tree t_addr = build1 (ADDR_EXPR, m_const_char_ptr, t_str);"

Note the "Loosely based" part.

That's because it doesn't handle things the same way the C/C++ frontends do, like doing proper type conversion, handling the various weird C cases and type degradation properly, etc.

The code to do this in the C frontend, including the type conversion/op building/etc for ADDR_EXPR necessary is about 200-300 lines of code.

For the record, i helped develop the GIMPLE IR in question, so i am in part at fault for the state of this part of the world. But it doesn't change anything i've said :P. It just may make you realize i'm not hating on anyone here

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

Reply on news.ycombinator.com