Run LLVM Assembly in the Browser
kripken.github.io
kripken.github.io
This information will be very useful to any compiler that uses LLVM as a back end, not just LLVM itself. Of course it may not be particularly useful to anyone else unless they're particularly interested in trying to diagnose why their code is being optimized in a certain way.
Only move instructions
It turns out that there's already a really easy way of executing compiler output on your CPU without the use of JavaScript...
It seems to be big
I suppose nowadays you can just use something like that to achieve similar thing?
>llc -mtriple=wasm32-unknown-unknown -O3 -filetype=obj main.ll -o main.o
>wasm-ld main.o -o main.wasm --no-entry -allow-undefined
Can wasm be optimized as much as llvm? Just wondering if we could have just put llvm in the browser.
Other commenters are correct that LLVM IR has more information in it than WebAssembly, but that is working as intended. The idea is that toolchains will do the heavy optimization work so that WebAssembly engines can be simpler and just do the final code generation.
[1] https://developer.chrome.com/native-client/nacl-and-pnacl
In contrast, LLVM IR is designed to be cpu- and OS-specific. Take a look at the very first line in the example: ‘target triple = "i386-pc-linux-gnu"’. Decidedly not web-friendly, though perhaps you could try to make a web triple?
The target triple isn't actually relevant in this demo, try setting it to "42" and it will still compile and run. For documentation so you know I'm not just bullshitting http://llvm.org/docs/LangRef.html#target-triple note that it's optional and can be overriden at compile time (which is what is happening here).
In a true browser implementation the target triple would be set to whatever platform the browser is running on, that way the browser compiled the web distributed IR straight to native code.
Google's PNACL, a precursor to WASM which shipped in Chrome, did exactly the above using LLVM IR. A web target triple was not needed as the LLVM IR was the web representation and the platform the browser was running on was the target triple. No need for a new web intermediary.
WASM works the same way, you distribute the representation and the browser converts it into a native target via compilation. WASM was designed to be less foreign to browser data structures/types and easier to implement in existing browser JS engines though. It's also easier to implement tiered compilation on. There are other reasons WASM was made instead of continuing to use LLVM IR but it's not because IR was CPU/OS specific.
LLVM does have web target triples though nowadays, wasm32 and wasm64. Previously it also had an asmjs target (which worked with standard JS engines at slower speeds without modification).