Looks cool, but could somebody explain what this would be used for? I'm guessing in situations between Native Code and JS? Looks a bit like .NET's IL.

ADD: Looking at the other comments, this is useful also as a platform to create languages, sort of a universal IL, yes?

> ADD: Looking at the other comments, this is useful also as a platform to create languages, sort of a universal IL, yes?

Not to my knowledge, it's solely an optimisation and codegen backend for webkit's FTL JIT (and possibly some other JIT sections in the future)

It's more like a tiny stripped-down (hence "bare bones") LLVM workalike for applications that value compilation speed highly, as far as I can tell.

I'd say that due to the input (JS), they also have a fairly limited set of IR constructs they really need to support. The B3 IR looks very simple for this reason. IOW, they figured out that for realistic code they don't need the full, heavy weight of LLVM and can just implement some simple basics.

Relevant, contains a lot of details: https://news.ycombinator.com/item?id=11103765

I wonder why they didn't go with LLVM IR, both WebKit and LLVM are essentially Apple products now.

There is already an LLVM backend in WebKit. I think the whole intention of the Bare Bones Backend is that it isn't LLVM. I can't find the link now, but I believe there are some design documents behind this where they critique the performance and output of LLVM, so they're trying something new.

LLVM does seem to struggle to support dynamic languages like JS well. For example Unladen Swallow (Python) and Rubinius (Ruby) were both commercially-backed efforts to use LLVM and neither achieved much performance.

> LLVM does seem to struggle to support dynamic languages like JS well. For example Unladen Swallow (Python) and Rubinius (Ruby) were both commercially-backed efforts to use LLVM and neither achieved much performance.

FTL has had no problems with performance of LLVM generated code as far as I'm aware: the problem has been the performance of the compilation itself, and as I understand it, that is the motivating factor here.

I can verify that LLVM ISel is quite slow. It's one of the main reasons why Rust is slower to compile than Go or OCaml.

(NB: The output is very high quality, so I still think it's the right choice for AOT. But slow compilation kills JITs.)

Isn't there a fast-isel that trades off output quality for compilation speed?

Yeah, but I don't think it's enough.

Maybe you're thinking about this discussion? https://trac.webkit.org/wiki/b3Discussion2015