Geoff:
artschnica data - JSC much faster on similar CPUs if we’re drawing to the screen, slightly slower for purely computational tasks

pizlo:
FTL motivation: use c-like compiler to do final optimizations
10-50x time spent in llvm as JSC code when compiling with FTL
b3 goal: reduce compiling time by 5x, this would increase scores on losing benchmarks
wrote new compiler from scratch, 10x faster compiling time than llvm
b3 uses better instruction selector, register allocator
llvm instruction selector uses most of its compile time
not done yet, probably measuring data within a month
targeting all 64-bit architectures, right now it works best on x86_64, working on arm64
b3ir has two div instructions, chillDiv does double division then converts to int, arm div is more like chillDiv
JSC regex engine slows down JetStream and Octane2 benchmarks
Kraken should speed up
llvm doesn’t do or want tail duplication optimization, which would speed up JSC
parallel compiling with llvm has a memory bottleneck, but works ok on computers with lots of CPU cores
Octane2 needs better garbage collection and better regex engine
goal is to be faster than Edge on all benchmarks
b3 - “barebones backend” - ssa “static single assignment” compiler like llvm
air - assembly intermediate representation

register allocation, macro assembler

“bacon, butter, biscuit” - appetizer at a restaurant in campbell
air probably takes more memory than b3
b3 is lowered to air
b3 equivalent of llvmir
air equivalent of mc

Michael:
calling conventions! We’re going to follow a calling convention. Almost C calling convention.
use more registers for arguments to prevent storing/loading on stack, which slows down code when calling functions
plan to follow calling conventions so that LLINT or baseline JIT can be called from anywhere
sometimes requires shuffling registers around so that parameters are in the correct registers
JSC on 64-bit platforms dedicate two registers to tag values, which are in callee-saved registers and need to be pushed and popped when using llvm because llvm has different register allocation than JSC
coalesces unnecessary mov operations
tail call optimizations (unrelated) allow recursive functions without adding to the stack each time.
if calling functions knows about the allocated registers in the function, it could break calling convention and do more optimizations, but if the function is recompiled, anything that calls it would need to be recompiled. — this is what inlining is for
armv7 doesn’t have enough registers for this optimization to be useful. i386 doesn’t have any registers for calling. pizlo: If we needed this optimization enough, we could invent our own calling convention.
pizlo: If a function is well-behaved, we should raise its inlining threshold
profiling bug - need profiling on math

rniwa: es6 slides