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.
"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.
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
