
Bare Bones Back end - ingve
https://webkit.org/docs/b3/
======
DanielBMarkham
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?

~~~
pcwalton
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.

~~~
eliben
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.

------
pizlonator
Relevant, contains a lot of details:
[https://news.ycombinator.com/item?id=11103765](https://news.ycombinator.com/item?id=11103765)

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

~~~
chrisseaton
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.

~~~
gsnedders
> 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.

~~~
pcwalton
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.)

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

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

------
BatFastard
Very nice optimizations. But you should reconsider the AIR name, since it will
get confused with the other AIR framework.

------
kelvin0
I (mis)read the title the first time: Bare Back Bones end ... I thought I was
in an alternate reality for a second ...

