Pith. sign in

REVIEW 4 major objections 5 minor 41 references

TPDE: A Fast Adaptable Compiler Back-End Framework

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read TPDE, a compiler back-end framework that adapts to existing SSA-form IRs, compiles LLVM-IR 8–24x faster than LLVM's -O0 pipeline while keeping generated-code run time within roughly 9 percent.

desk verdict A genuinely useful, reusable fast back-end framework with strong engineering, but the SPECint headline needs the missing 648.exchange2 explained before it is fully trustworthy. read the letter →

arxiv 2505.22610 v1 pith:YLOTOE3Y submitted 2025-05-28 cs.PL

Tobias Schwarz (1) , Tobias Kamm (1) , Alexis Engelke (1) ((1) Technical University of Munich) This is my paper
classification cs.PL
keywords compilerback-endjust-in-timecompilationSSAformsingle-passcodegenerationregisterallocationinstructionselectionLLVMIRsnippetencoding
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper presents TPDE, a compiler back-end framework that claims a reusable middle path between hand-written fast code generators and general-purpose compiler frameworks. The framework adapts to any existing SSA-form IR through a thin adapter, runs one liveness and loop analysis pass, then compiles each function in a single pass that fuses instruction selection, register allocation, and machine-code encoding. The authors build a complete LLVM-IR back-end on this framework and report compile times 8–24x faster than LLVM's unoptimized -O0 pipeline on SPECint 2017, with generated code running within about 9 percent of LLVM -O0 output. They also report faster or comparable compilation for WebAssembly and database-query IRs. If these results hold, JIT systems could replace custom baseline compilers with a portable framework instead of writing and maintaining a hand-rolled back-end for each IR and architecture.

What carries the argument

The load-bearing mechanism is the two-pass structure: a fast analysis pass computes liveness and loop structure from the Kohn et al. liveness algorithm combined with the Wei et al. loop-finder, which supports irreducible loops, and chooses a reverse-post-order block layout that keeps live ranges short; then a strictly local, greedy single code-generation pass performs instruction selection, register allocation, spilling, and encoding in one forward sweep. The second key mechanism is the snippet encoder: a separate tool compiles hand-written C/C++ semantics through LLVM down to target Machine IR, then generates C++ encoder functions that, at TPDE compile time, materialize operands, merge constants and addressing modes into instructions, reuse registers of dead operands, and emit the final machine code. Together, these allow instruction compilers to be written mostly architecture-independently while the framework handles register pressure, ABI, phi-node moves, prologue patching, and object-file emission.

What would settle it

Compile a corpus of hand-constructed SSA functions with deeply nested and irreducible loops, where values are defined outside a loop and used at its far end, and compare TPDE's compile time and generated-code run time against LLVM -O0 on the same functions; if the 8–24x compile-time speedup or the ±9% run-time parity fails on any such input, the framework's central claim would be falsified.

Watch

Extended reading notes

Core claim

The central claim is that a compiler back-end does not need its own IR or a multi-stage lowering pipeline to be both fast and adaptable. TPDE defines two interfaces: an IR adapter that exposes blocks, values, operands, and phi-nodes of an existing SSA IR in a canonical form, and instruction compilers that specify the semantics of each IR operation. With only those, the framework performs a linear-time liveness and loop analysis, determines a block layout, and then emits code in a single forward pass, deciding instruction selection, register allocation, spilling, and encoding together. To keep instruction compilers portable, target instruction sequences are extracted from LLVM's Machine IR and turned into generated snippet encoders that dynamically choose registers, immediates, and addressing modes. The paper reports that this design compiles SPECint 2017 LLVM-IR 8–24x faster than LLVM -O0 (geomean 12.15x on x86-64, 18.96x on AArch64) while generated code stays within ±9% run-time, and that it ports to a database query compiler with compile-time and run-time on par with that system's specialized direct-emission back-end.

Load-bearing premise

The load-bearing assumption is that the analysis used to detect which values are still needed, combined with the chosen block ordering, is correct and fast enough on every possible program shape; if an unusual loop structure makes values stay live too long, the generated code's speed would fall out of the claimed range.

Editorial extensions

If this is right

  • JIT runtimes that already lower to LLVM-IR could adopt the TPDE LLVM back-end as a baseline compiler, cutting back-end latency to roughly 2% of total compile time instead of the roughly 15% the paper attributes to LLVM's pipeline.
  • Adapting TPDE to a new SSA IR requires only the adapter and instruction compilers; the framework supplies register allocation, spilling, ABI handling, phi-node lowering, exception unwind info, and object-file emission by default.
  • Porting the LLVM back-end to AArch64 took days and mostly simple logic because snippet encoders make most instruction compilers architecture-independent; the whole LLVM back-end is under 8k lines of code.
  • Compiling optimized (-O1) LLVM-IR with TPDE is still roughly 16–19x faster than the LLVM -O0 pipeline, but the generated code is 1.5–1.8x slower than LLVM -O1 code, so TPDE is positioned as a replacement for the fast baseline rather than for the optimizing pipeline.
  • Avoiding the extra IR translation matters: for the database query IR, the native TPDE adapter compiles substantially faster than first translating to LLVM-IR, while matching the specialized direct-emission back-end in both compile-time and run-time.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural next experiment is to stress-test the block layout and liveness assumptions on adversarial control-flow graphs: if functions with many irreducible loops and long cross-loop live ranges break the ±9% run-time parity, the framework would need either a second register-allocation pass or better layout heuristics.
  • Because snippet encoders are generated from LLVM's Machine IR, TPDE inherits the instruction vocabulary and encoding options of whatever LLVM version produced the MIR; tracking LLVM API changes may be a hidden maintenance cost the paper does not quantify.
  • The same adapter-plus-snippet architecture could plausibly be extended to produce snippets from other compiler back-ends' instruction definitions, which would make the framework less dependent on LLVM's Machine IR as the extraction source.
  • The reported code-size increase (43–49%) comes mostly from prologues that reserve space for all callee-saved registers; a future refinement that emits only the registers actually used would likely close most of the size gap without hurting compile time.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper introduces TPDE, a compiler back-end framework that compiles SSA-form IRs directly, without requiring an intermediate IR translation. The framework is adapted to a given IR through an IR adapter and a set of instruction compilers; it performs one analysis pass (liveness and loop analysis) and one code-generation pass that combines instruction selection, register allocation, and instruction encoding. To ease porting, the authors provide a snippet-encoder generator that extracts target instruction sequences from LLVM's Machine IR. They evaluate TPDE by implementing back-ends for LLVM-IR (x86-64/AArch64), Cranelift/WebAssembly, and Umbra's database query IR. The headline results are an 8-24x compile-time speedup over LLVM -O0 with run-time within ±9% on SPECint 2017, and on-par compile/run performance with Umbra's DirectEmit back-end.

Significance. If the results hold, TPDE is a valuable contribution: it offers a reusable, IR-adaptive alternative to hand-written fast back-ends, with a single-pass code generator that maintains code quality close to LLVM -O0. The paper's strengths include a released implementation, comparisons against multiple external baselines (LLVM -O0/-O1, Cranelift, Winch, DirectEmit, and copy-and-patch), and three distinct IR case studies demonstrating generality. The evaluation is not steered by fitted parameters or self-referential normalization. However, the headline claims are currently supported by incomplete benchmark data, and some stated limitations raise questions about the representativeness of the SPECint results.

major comments (4)
  1. [Section 5.2, Figures 5a/5b and 8a/8b] SPEC CPU2017's integer suite consists of ten benchmarks, but Figures 5 and 8 report results for only nine: 600.perlbench, 602.gcc, 605.mcf, 620.omnetpp, 623.xalancbmk, 625.x264, 631.deepsjeng, 641.leela, and 657.xz. 648.exchange2 is absent, and Section 5.2 gives no reason for its omission. Because the abstract and Section 5.2.2 state the 8-24x compile-time speedup and the ±9% run-time parity claims without qualification, the missing benchmark could materially change the geomeans (12.15x on x86-64 and 18.96x on AArch64) and the claimed range. The authors should either include 648.exchange2 or explicitly exclude it and rephrase the claims as applying to a subset of SPECint 2017.
  2. [Section 5.1 vs Section 5.2] Section 5.1 states that the LLVM-IR back-end excludes vector types and other uncommon constructs, yet Section 5.2 reports results for 625.x264, a SPECint 2017 benchmark that uses SIMD intrinsics and is likely to produce vector-typed LLVM IR even at -O0. The paper does not explain how this benchmark was compiled under that exclusion. If vector operations were lowered or the benchmark was run with non-standard configuration flags, this must be disclosed; otherwise, the reported SPECint coverage is inconsistent with the stated limitations of the back-end.
  3. [Section 5.2.2] The run-time parity claim (±9% of LLVM -O0) is based on aggregate geomeans with no error bars, confidence intervals, or reported number of runs. Figure 5b shows per-benchmark speedups, but without variance information the claim is not statistically supported. Please report run-to-run variability and state how many compilation and execution repetitions were averaged for both the compile-time and run-time measurements.
  4. [Section 3.3] The analysis pass combines the liveness algorithm of Kohn et al. with the loop analysis of Wei et al. to support irreducible loops. The paper provides no correctness argument or empirical stress test for this specific combination, and Wei et al. is cited as having worst-case O(N·E) running time. The single-pass register allocator relies on the resulting live ranges and block layout; if the combined analysis is incorrect or degrades on irreducible CFGs, the run-time parity claim could break. Please provide either a correctness argument for the combination or an experimental validation on CFGs with irreducible loops and multi-edges.
minor comments (5)
  1. [Section 5.2.2] The sentence 'with TPDE only 2% of the time are spent inside the back-end, compared to 15% with the default LLVM back-end (average speedup of end-to-end compilation: 17%)' appears numerically inconsistent; please verify the arithmetic and clarify whether the speedup is relative to full Clang invocation.
  2. [Section 4.4.2, Figure 4b] The snippet in Figure 4b contains a truncated line ('return a << 64+(amt%'); please complete the code example.
  3. [Figure 5a] The numeric labels on Figure 5a appear to include values above 24x; please reconcile the visible axis labels with the stated 8-24x range.
  4. [Section 3.1.2] The paper notes that TPDE does not support multi-edges between blocks with different values; this limitation is acknowledged but not discussed in the evaluation sections. Please state whether any of the evaluated IRs required multi-edge workarounds (as is done for CLIF in Section 6.1.1) and whether this affects the LLVM-IR case.
  5. [Section 1 and Section 5.2.1] The paper states the code is available at a GitHub repository but does not provide a pinned commit hash or the raw benchmark data; adding these would improve reproducibility and make the artifact easier to audit.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation: TPDE's compile-time and run-time claims are direct measurements against external baselines (LLVM, Cranelift, Winch, DirectEmit) on public benchmark suites; the unexplained absence of SPECint 648.exchange2 from Figures 5, 7, and 8 is a completeness gap, not a circular step.

full rationale

The paper's central claims — 8–24x compile-time speedup over the LLVM -O0 back-end, ±9% run-time parity, and faster compilation for Wasmtime and Umbra — are empirical measurements of a released implementation against external systems on public benchmarks (SPECint 2017, Sightglass, PolyBench, TPC-DS). No parameter is fitted to a subset of the data and then renamed as a prediction; the evaluation contains no fitted inputs, no normalization anchored to the claimed quantities, and no equation that reduces to its own input. The only subtle provenance issue is Section 4: snippet encoders are extracted from LLVM's own Machine IR, so part of the instruction selection echoes LLVM — but run-time parity is measured, not forced by construction, as the copy-and-patch baseline [14] reuses machine-code templates and is still 2.38x slower than LLVM -O0 (Figure 5b). The two self-citations with any premise weight are non-load-bearing: [15] supports 'the compilation times of LLVM are generally high' (Section 1), a premise independently re-measured here (Figures 5–6), and [14] is merely an external baseline being compared against (Section 5.2.1). No uniqueness theorem is imported, no ansatz is smuggled in via citation, and no known result is renamed. One flagged gap is a correctness risk, not circularity: Figures 5a/5b, 7, and 8a/8b show only nine of the ten SPECint 2017 programs — 600.perlbench through 657.xz — with 648.exchange2 absent and Section 5.2 never explaining the omission, so the headline geomeans (12.15x x86-64; 18.96x AArch64) could move if that benchmark were added. The paper also states its own scoping limitations (unsupported vector types and inline assembly, Section 5; no constant folding, Section 4.4.2; no function calls or stack frames in snippet encoders, Section 4.1.4), which further confirms the claims are bounded empirical results rather than constructed tautologies.

Assumptions & free parameters 0 free parameters · 3 assumptions · 1 invented entities

No numeric parameters are fitted to benchmark results; the framework's heuristics are qualitative design choices. The main unproved premises are correctness of the cited liveness and loop analyses, the SSA-form limitation, and the safety of ignoring implicit registers in snippet encoders.

assumptions (3)
  • domain assumption The input IR is in strict SSA form, without multi-edges between blocks carrying different values.
    Section 3.1.2 states TPDE is designed around IRs in strict SSA form and does not currently support multi-edges, which limits the set of adaptable IRs.
  • standard math The liveness analysis from Kohn et al. and the loop analysis from Wei et al. are correct and efficient for all CFGs, including irreducible loops.
    Section 3.3 relies on these cited algorithms without a formal proof of their combination; the run-time and code-quality claims depend on their correctness.
  • domain assumption Ignoring implicit registers such as flags in Machine IR snippets is safe when instruction order is preserved.
    Section 4.1.3 states this explicitly; correctness of the generated code depends on the emitted sequence preserving all implicit data-flow dependencies.
invented entities (1)
  • TPDE framework independent evidence
    purpose: Reusable single-pass back-end framework that adapts to external SSA IRs
    The public GitHub repository (https://github.com/tpde2/tpde) provides an external implementation against which the claims can be checked, though no commit hash is cited.

how reviews work

0 comments
Cite this review

Pith. "Pith review of TPDE: A Fast Adaptable Compiler Back-End Framework." pith.science (2026). https://pith.science/paper/YLOTOE3Y

@misc{pith2026250522610,
  author       = {Pith},
  title        = {Pith review of: TPDE: A Fast Adaptable Compiler Back-End Framework},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YLOTOE3Y}},
  note         = {Machine review of arXiv:2505.22610}
}
read the original abstract

Fast machine code generation is especially important for fast start-up just-in-time compilation, where the compilation time is part of the end-to-end latency. However, widely used compiler frameworks like LLVM do not prioritize fast compilation and require an extra IR translation step increasing latency even further; and rolling a custom code generator is a substantial engineering effort, especially when targeting multiple architectures. Therefore, in this paper, we present TPDE, a compiler back-end framework that adapts to existing code representations in SSA form. Using an IR-specific adapter providing canonical access to IR data structures and a specification of the IR semantics, the framework performs one analysis pass and then performs the compilation in just a single pass, combining instruction selection, register allocation, and instruction encoding. The generated target instructions are primarily derived code written in high-level language through LLVM's Machine IR, easing portability to different architectures while enabling optimizations during code generation. To show the generality of our framework, we build a new back-end for LLVM from scratch targeting x86-64 and AArch64. Performance results on SPECint 2017 show that we can compile LLVM-IR 8--24x faster than LLVM -O0 while being on-par in terms of run-time performance. We also demonstrate the benefits of adapting to domain-specific IRs in JIT contexts, particularly WebAssembly and database query compilation, where avoiding the extra IR translation further reduces compilation latency.

Figures

Figures reproduced from arXiv: 2505.22610 by the authors.

Figure 1
Figure 1. Overview of the TPDE compilation framework. The framework adapts to any IR in SSA form through an [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Functionality required from an IR adapter. All instances are referred to by handles; [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Overview of the snippet encoder generator targeting AArch64. Semantics are specified in a high-level [PITH_FULL_IMAGE:figures/full_fig_p010_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Although constant operands are folded into snippets, instructions with all-constant inputs are not [PITH_FULL_IMAGE:figures/full_fig_p014_4.png]
Figure 5
Figure 5. Figure 5: Compile- and Run-time speedup normalized to LLVM [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 6
Figure 6. Figure 6: Time distribution when compiling all SPECint [PITH_FULL_IMAGE:figures/full_fig_p017_6.png]
Figure 8
Figure 8. Figure 8: Compile- and Run-time speedup normalized to the LLVM [PITH_FULL_IMAGE:figures/full_fig_p018_8.png]
Figure 9
Figure 9. Figure 9: Compile- and Run-time speedup normalized to Cranelift with the default register allocator on three [PITH_FULL_IMAGE:figures/full_fig_p020_9.png]
Figure 10
Figure 10. Figure 10: Compile- and run-time accumulated over all TPC-DS queries at scale factor 1. Compilation is repeated [PITH_FULL_IMAGE:figures/full_fig_p021_10.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

41 extracted references · 38 canonical work pages

  1. [1]

    AsmJit Authors. 2024. AsmJit. https://asmjit.com/, accessed 2024-11-12. 24 Tobias Schwarz, Tobias Kamm, and Alexis Engelke

    work page 2024

  2. [2]

    Fabrice Bellard. 2005. QEMU, a fast and portable dynamic translator. InUSENIX Annual Technical Conference, FREENIX Track, Vol. 41. 46

    work page 2005

  3. [3]

    Shah, and Alan Edelman

    Jeff Bezanson, Stefan Karpinski, Viral B. Shah, and Alan Edelman. 2012. Julia: A Fast Dynamic Language for Technical Computing. (2012). arXiv:1209.5145 [cs.PL] https://arxiv.org/abs/1209.5145

    arXiv 2012

  4. [4]

    Benoit Boissinot, Sebastian Hack, Daniel Grund, Benoît Dupont de Dine hin, and Fabrice Rastello. 2008. Fast liveness checking for SSA-form programs. InProceedings of the 6th annual IEEE/ACM international symposium on Code Generation and Optimization. 35–44

    work page 2008

  5. [5]

    Brandt Bucher and Savannah Ostrowski. 2024. PEP 744 — JIT Compilation. https://peps.python.org/pep-0744/, accessed 2024-11-10

    work page 2024

  6. [6]

    Bytecode Alliance. 2023. Cranelift. https://cranelift.dev/, accessed 2023-05-19

    work page 2023

  7. [7]

    Bytecode Alliance. 2023. Cranelift compared to LLVM. https://github.com/bytecodealliance/wasmtime/blob/28931a4/ cranelift/docs/compare-llvm.md, accessed 2023-05-19

    work page 2023

  8. [8]

    Bytecode Alliance. 2023. Wasmtime. https://wasmtime.dev/, accessed 2023-05-19

    work page 2023

Show all 41 references
  1. [9]

    Bytecode Alliance. 2025. Cranelift IR Reference. https://github.com/bytecodealliance/wasmtime/blob/ 6a8d3d5a9ad32aa63cc39b657ec7352882dd5d70/cranelift/docs/ir.md, accessed 2025-03-25

    2025

  2. [10]

    Bytecode Alliance. 2025. Sightglass – A benchmarking suite and tooling for Wasmtime and Cranelift. https://github. com/bytecodealliance/sightglass, accessed 2025-03-24

    2025

  3. [11]

    Clang Team. 2016. Clang-Repl. https://releases.llvm.org/20.1.0/tools/clang/docs/ClangRepl.html, accessed 2025-03-20

    2016

  4. [12]

    Rosen, Mark N

    Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. 1991. Efficiently computing static single assignment form and the control dependence graph. 13, 4 (1991), 451–490. https://doi.org/10.1145/115372. 115320

    1991 doi

  5. [13]

    Cristian Diaconu, Craig Freedman, Erik Ismert, Per-Åke Larson, Pravin Mittal, Ryan Stonecipher, Nitin Verma, and Mike Zwilling. 2013. Hekaton: SQL server’s memory-optimized OLTP engine. InProceedings of the 2013 ACM SIGMOD International Conference on Management of Data. ACM, 1243–1254

    2013

  6. [14]

    Florian Drescher and Alexis Engelke. 2024. Fast Template-Based Code Generation for MLIR. InProceedings of the 33rd ACM SIGPLAN International Conference on Compiler Construction. 1–12

    2024

  7. [15]

    Alexis Engelke and Tobias Schwarz. 2024. Compile-Time Analysis of Compiler Frameworks for Query Compilation. In 2024 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). 233–244

    2024

  8. [16]

    Anton Ertl and David Gregg

    M. Anton Ertl and David Gregg. 2004. Retargeting JIT compilers by using C-compiler generated executable code. In Proceedings. 13th International Conference on Parallel Architecture and Compilation Techniques, 2004. PACT 2004.41–50. https://doi.org/10.1109/PACT.2004.1342540

    2004 arXiv

  9. [17]

    Henning Funke, Jan Mühlig, and Jens Teubner. 2020. Efficient generation of machine code for query compilers. In DaMoN. ACM, 6:1–6:7

    2020

  10. [18]

    Ferdinand Gruber, Maximilian Bandle, Alexis Engelke, Thomas Neumann, and Jana Giceva. 2023. Bringing Compiling Databases to RISC Architectures.Proceedings of the VLDB Endowment16, 6 (2023), 1222–1234

    2023

  11. [19]

    Tim Gubner and Peter A. Boncz. 2021. Charting the Design Space of Query Execution using VOILA.Proc. VLDB Endow.14, 6 (2021), 1067–1079

    2021

  12. [20]

    Timo Kersten, Viktor Leis, and Thomas Neumann. 2021. Tidy Tuples and Flying Start: fast compilation and fast execution of relational queries in Umbra.The VLDB Journal30 (2021), 883–905

    2021

  13. [21]

    Gary A. Kildall. 1973. A unified approach to global program optimization. InProceedings of the 1st annual ACM SIGACT-SIGPLAN symposium on Principles of Programming Languages. 194–206

    1973

  14. [22]

    André Kohn, Viktor Leis, and Thomas Neumann. 2018. Adaptive Execution of Compiled Queries. In2018 IEEE 34th International Conference on Data Engineering (ICDE). 197–208. https://doi.org/10.1109/ICDE.2018.00027

    2018

  15. [23]

    Chris Lattner and Vikram Adve. 2004. LLVM: A compilation framework for lifelong program analysis & transformation. InInternational Symposium on Code Generation and Optimization (CGO)

    2004

  16. [24]

    Chris Lattner, Mehdi Amini, Uday Bondhugula, Albert Cohen, Andy Davis, Jacques Pienaar, River Riddle, Tatiana Shpeisman, Nicolas Vasilache, and Oleksandr Zinenko. 2021. MLIR: Scaling compiler infrastructure for domain specific computation. In2021 IEEE/ACM International Symposi...

    2021

  17. [25]

    Dmitry Melnik. 2016. Speeding up query execution in PostgreSQL using LLVM JIT compiler. https://llvm.org/devmtg/ 2016-09/slides/Melnik-PostgreSQLLLVM.pdf, accessed 2024-11-10

    2016

  18. [26]

    Thomas Neumann. 2011. Efficiently compiling efficient query plans for modern hardware.Proceedings of the VLDB Endowment4, 9 (2011), 539–550. https://doi.org/10.14778/2002938.2002940

    2011

  19. [27]

    Thomas Neumann and Michael Freitag. 2020. Umbra: A Disk-Based System with In-Memory Performance.. InCIDR

    2020

  20. [28]

    Michael Paleczny, Christopher Vick, and Cliff Click. 2001. The Java HotSpot server compiler. InSymposium on Java Virtual Machine Research and Technology Symposium (JVM). 1–12

    2001

  21. [29]

    Gregor Peach, Runyu Pan, Zhuoyi Wu, Gabriel Parmer, Christopher Haster, and Ludmila Cherkasova. 2020. eWASM: Practical software fault isolation for reliable embedded devices.IEEE Transactions on Computer-Aided Design of TPDE: A Fast Adaptable Compiler Back-End Framework 25 Int...

    2020

  22. [30]

    Filip Pizlo. 2016. https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/, accessed 2023-05-14

    2016

  23. [31]

    Yuki Pouchet, Bondugula. 2016. PolyBench. https://github.com/MatthiasJReisinger/PolyBenchC-4.2.1, accessed 2025-03-24

    2016

  24. [32]

    2012.On Sparse Intermediate Representations: Some Structural Properties and Applications to Just-In-Time Compilation

    Fabrice Rastello. 2012.On Sparse Intermediate Representations: Some Structural Properties and Applications to Just-In-Time Compilation. Habilitation thesis. Inria Grenoble Rhône-Alpes

    2012

  25. [33]

    Leszek Swirski. 2021. Sparkplug – a non-optimizing JavaScript compiler. https://v8.dev/blog/sparkplug, accessed 2025-03-20

    2021

  26. [34]

    Ben L. Titzer. 2024. Whose baseline compiler is it anyway?. In2024 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). 207–220

    2024

  27. [35]

    TPC. [n. d.]. TPC-DS Decision Support Benchmark. https://www.tpc.org/tpcds/, accessed 2023-05-14

    2023

  28. [36]

    V8 Project. [n. d.]. TurboFan. https://v8.dev/docs/turbofan, accessed 2025-03-20

    2025

  29. [37]

    Toon Verwaest, Leszek Swirski, Victor Gomes, Olivier Flückiger, Darius Mercadier, and Camillo Bruni. 2023. Maglev – V8’s Fastest Optimizing JIT. https://v8.dev/blog/maglev, accessed 2025-03-20

    2023

  30. [38]

    WebKit Developers. [n. d.]. WebKit: Bare Bones Backend. https://webkit.org/docs/b3/, accessed 2024-11-07

    2024

  31. [39]

    WebKit Developers. [n. d.]. WebKit Wiki: JavaScriptCore. https://trac.webkit.org/wiki/JavaScriptCore, accessed 2025-02-08

    2025

  32. [40]

    Tao Wei, Jian Mao, Wei Zou, and Yu Chen. 2007. A new algorithm for identifying loops in decompilation. InProceedings of the 14th International Conference on Static Analysis(Kongens Lyngby, Denmark)(SAS’07). Springer-Verlag, Berlin, Heidelberg, 170–183

    2007

  33. [41]

    Haoran Xu and Fredrik Kjolstad. 2021. Copy-and-patch compilation: a fast compilation algorithm for high-level languages and bytecode.Proceedings of the ACM on Programming Languages5, OOPSLA (2021), 1–30

    2021

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.