Pith. sign in

REVIEW 2 major objections 5 minor 3 cited by

WAMI: Compilation to WebAssembly through MLIR without Losing Abstraction

T0 review · 2 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read This paper claims that a pipeline using two new MLIR dialects can generate high-level WebAssembly directly from MLIR, bypassing LLVM, and remain within 7.7% of LLVM's performance.

desk verdict Solid MLIR-to-Wasm dialect design and a real stack-switching case study, but the abstract overstates the performance claim and there is no artifact. read the letter →

arxiv 2506.16048 v1 pith:RDHBPZUN submitted 2025-06-19 cs.PL

Byeongjee Kang , Harsh Desai , Limin Jia , Brandon Lucia This is my paper
classification cs.PL
keywords WebAssemblyMLIRdialectconversioncompilerpipelinestackswitchingdelimitedcontinuationscodegenerationabstractionpreservation
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 claims that targeting WebAssembly from MLIR does not require lowering to LLVM IR first, and that skipping that step preserves the high-level structure that modern Wasm features need. The authors introduce two new MLIR dialects, an SSA-style dialect with explicit operands and results and a stack-based dialect that mirrors Wasm semantics, plus conversion passes that lower common MLIR dialects directly into Wasm. They evaluate the pipeline on the PolyBench benchmark suite and report that the resulting binaries are at most 7.7% slower than LLVM-generated code, and faster in some execution environments. If these claims hold, MLIR-based compilers can adopt high-level Wasm features such as stack switching without waiting for LLVM IR support.

What carries the argument

The load-bearing mechanism is the pair of new MLIR dialects and the conversion passes that connect them. SsaWasm represents Wasm operations with explicit SSA operands and results so standard MLIR transformations can run on them, while the Wasm dialect captures the stack-based semantics needed for direct text emission. Composite operations like ssawasm.block_loop and ssawasm.block_block model Wasm's structured block and loop nesting, with auxiliary operations such as pseudo_br and on_stack making implicit stack transfers explicit enough for MLIR passes. This design lets high-level dialects lower directly to Wasm without a control-flow restructuring step, and it exposes address arithmetic as ordinary SsaWasm operations so MLIR's common-subexpression elimination and constant folding apply.

What would settle it

Compile the PolyBench suite with WAMI and with LLVM, then run both binaries on a minimal pure interpreter that performs no ahead-of-time or just-in-time optimization; if the average WAMI slowdown exceeds the paper's worst-case 7.7%, the performance-parity claim collapses.

Watch

Extended reading notes

Core claim

WAMI's central claim is that WebAssembly should be a first-class target inside the MLIR ecosystem rather than an LLVM backend output. The paper introduces the SsaWasm dialect, which models Wasm instructions in static single-assignment form with explicit operands, results, typed local variables, and continuation references, and a lower Wasm dialect that mirrors the stack-based textual format. Conversion passes lower Arith, MemRef, Func, and SCF dialects directly into SsaWasm, using composite operations such as block_loop and block_block to preserve Wasm's structured control flow, and then translate SsaWasm to Wasm through an introduce-locals pass and a direct operation mapping. To show extensibility, the paper defines a delimited-continuation dialect (DCont) and compiles generator and cooperative-scheduler examples to Wasm using the stack-switching proposal's continuation instructions. The performance section reports that WAMI-generated code is at most 7.7% slower than LLVM-generated code on interpreters, about 4.1% slower on Wasmtime's ahead-of-time mode, and about 1.9% faster on WAMR's ahead-of-time mode, with a 10.0% mean speedup on a classic stack-based interpreter.

Load-bearing premise

The performance-parity claim assumes that WebAssembly runtimes will supply the low-level optimizations WAMI omits; on a runtime with only a simple, non-optimizing interpreter, WAMI-generated code could be substantially slower than LLVM-generated code.

Editorial extensions

If this is right

  • MLIR-based compilers can adopt new Wasm proposals by writing conversion passes from high-level dialects instead of waiting for LLVM IR support.
  • Compilers that already target MLIR can generate Wasm without depending on LLVM's backend, reducing the engineering needed to track Wasm changes.
  • The stack-switching case study shows that coroutine-like non-local control flow can be compiled directly to Wasm's continuation instructions, avoiding reconstruction layers.
  • Because address computations are explicit in SsaWasm, MLIR optimizations can optimize them, partly compensating for the lack of LLVM backend optimizations.
  • On runtimes whose ahead-of-time compilers re-optimize the final Wasm binary, the quality of the initial generated code matters less, so WAMI remains competitive.

Reading between the lines

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

  • Inference: if runtime ahead-of-time or just-in-time compilation keeps absorbing low-level optimization work, WAMI-style pipelines could let MLIR-based languages ship a much smaller compiler backend, provided the runtime remains optimizing.
  • Inference: the measured speedup on a classic stack-based interpreter suggests LLVM's CPU-oriented transformations can hurt interpreter performance, which points to interpreter-only embedded targets as the clearest win for this approach.
  • Inference: a direct testable extension is to add a garbage-collection dialect conversion to the same pipeline and compare code size and runtime against LLVM's experimental WebAssembly GC path; the paper's design predicts faster feature adoption but does not itself evaluate GC performance.
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

2 major / 5 minor

Summary. The paper presents WAMI, an MLIR-based compilation pipeline for WebAssembly. It introduces two new MLIR dialects: SsaWasm, an SSA-form representation of Wasm with explicit operands and results, and Wasm, a stack-based dialect that mirrors Wasm's textual format. Conversion passes are described from the Arith, MemRef, Func, and SCF dialects to SsaWasm, and from SsaWasm to the Wasm dialect and finally to Wasm text. The paper also presents DCont, a prototype dialect for delimited continuations, and lowers it to SsaWasm using the Stack Switching proposal. The evaluation compiles PolyBench C benchmarks (via Polygeist) with both WAMI and an LLVM-based path, runs the resulting Wasm on Wasmtime and WAMR under interpreter and AoT execution modes, and reports mean slowdowns of 6.7% and 7.7% on interpreters, 4.1% on Wasmtime AoT, and a 1.9% speedup on WAMR AoT. The central claim is that WAMI can generate Wasm directly from high-level MLIR dialects without losing abstraction, while retaining competitive performance with LLVM-based compilers.

Significance. The core idea—making Wasm a first-class MLIR target and bypassing LLVM IR for Wasm code generation—is timely and plausible, and the Stack Switching case study demonstrates a concrete extensibility path that existing LLVM-based pipelines cannot easily provide. The paper is also transparent about WAMI's reliance on runtime AoT/JIT optimizations and on Binaryen, and the evaluation covers two very different platforms, which strengthens the empirical picture. The main weakness is that the headline performance bound is overstated by the paper's own data, and one of the central conversion-pass examples appears to be incorrect as printed. If these issues are fixed, the contribution would be a useful building block for the MLIR and WebAssembly compiler communities.

major comments (2)
  1. [Section 5.1, Figure 9] The displayed scf.for-to-SsaWasm conversion is not semantically correct as written. The termination condition at line 9 is `arith.cmpi eq, %i, %ub`, which would only enter the loop body when the induction variable equals the upper bound, rather than the usual less-than comparison of scf.for. More seriously, the loop-carried variable is never updated: line 19 writes `%new_acc` to `%result`, but the next iteration's `%acc_val` at line 12 still reads the old `%acc` local, so `%acc` remains at its initial value forever. The snippet also uses `%num` at line 13 without defining it. Please correct the figure, or clarify if it is only an illustrative sketch; as printed, it does not match the semantics the pass is supposed to implement.
  2. [Abstract and Section 7.2, Figure 14] The abstract's claim that WAMI 'produces code with at most 7.7% slower' is not supported by the reported data. Section 7.2 lists mean slowdowns (6.7% on Wasmtime interpreter, 7.7% on WAMR interpreter, 4.1% on Wasmtime AoT, and a 1.9% speedup on WAMR AoT) and calls 7.7% the 'worst case,' but Figure 14 plots per-benchmark ratios and several bars clearly exceed 1.077, with values around 1.2–1.4 corresponding to 20–40% per-benchmark slowdowns. The 'at most' phrasing should be replaced by 'on average,' or the per-benchmark worst case should be reported and the claim adjusted accordingly. This is a headline quantitative claim and needs to be stated accurately.
minor comments (5)
  1. [Section 4.1] The text refers to 'Table 3' when presenting the SsaWasm types and operations, but the content appears in Figure 3; please fix the cross-reference.
  2. [Title and Abstract] The phrase 'without losing abstraction' is stronger than what the paper demonstrates: high-level SCF/MemRef/Affine abstractions are lowered to SsaWasm, and what is preserved is enough semantic information to emit high-level Wasm features. Consider qualifying the wording, e.g., 'without losing the abstraction level needed to use high-level Wasm features.'
  3. [Section 7.1] The experimental methodology does not state the number of repetitions per benchmark, whether the reported numbers are means or medians across runs, or whether the benchmark outputs were verified for correctness; please add this information.
  4. [General] No artifact or repository URL is provided for the WAMI implementation. Making the code available would substantially strengthen reproducibility, especially since the paper describes a compiler implementation.
  5. [Section 7.2] The WAMR configuration descriptions are confusing: the initial results list a 7.7% mean slowdown on the WAMR interpreter, but later the 17.0% 'without AoT' result and the 10.0% classic-interpreter speedup are introduced without clearly explaining which interpreter mode each number corresponds to. Please reconcile these numbers and clearly label the interpreter variants.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: WAMI's claims are established by implementation and external-baseline evaluation, not by definition or self-citation.

full rationale

The paper's central claims are (1) a compiler pipeline using new MLIR Wasm dialects and conversion passes, and (2) measured performance comparable to LLVM-generated Wasm. Neither claim reduces to its own inputs. The dialect conversions are defined semantically (Sections 4-6) and validated by executing generated Wasm (e.g., Wasmfxtime for Stack Switching in Section 6.2), not by fitting to the evaluation data. The performance comparison in Section 7 is against an external baseline: PolyBench C via Polygeist is compiled by both WAMI and LLVM, and the resulting binaries are timed on Wasmtime and WAMR. No parameter is fitted to the benchmarks and then reported as a prediction; the reported slowdowns are direct measurements. The authors explicitly attribute part of the competitive result to downstream runtime AoT compilation (Section 7.2), which is a stated assumption, not a circular inference. The paper contains no author self-citation used as evidence, and no uniqueness theorem or ansatz is imported from prior work. The abstract's 'at most 7.7% slower' is arguably an overstatement relative to the per-benchmark bars in Fig. 14, but overstatement of an empirical claim is not circularity. The architectural claim of 'without losing abstraction' is supported by the design (dialect conversion from SCF and DCont directly to SsaWasm/Wasm rather than through LLVM IR); one could debate whether the pipeline truly preserves all abstractions, but that is a design-correctness question, not a reduction of the result to its inputs. No circular step can be exhibited.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The paper introduces no free parameters because it makes no quantitative predictions fitted to data. The new MLIR dialects (SsaWasm, Wasm, DCont) are implementation artifacts, not postulated theoretical entities; the axioms listed are the domain and tooling assumptions the central claims depend on.

assumptions (5)
  • domain assumption Wasm's execution model does not require register allocation or instruction scheduling, so bypassing LLVM's machine code generation is practical.
    Section 3 argues that Wasm has no fixed physical registers and that runtimes handle scheduling, justifying the absence of LLVM backend optimizations.
  • domain assumption Existing MLIR optimization passes and Binaryen optimizations are sufficient to achieve performance competitive with LLVM.
    Section 7 evaluates this empirically, but the assumption is load-bearing: WAMI relies entirely on MLIR and Binaryen passes, not on LLVM's optimization suite.
  • domain assumption Treating memref.alloca as memref.alloc in four benchmarks does not invalidate the performance comparison because heap allocation is slower than stack allocation.
    Section 7.1 makes this assumption to justify modifying durbin, gramschmidt, ludcmp, and symm. It is a conservative bias, but changes the benchmarks and relies on the speed ordering.
  • domain assumption The Stack Switching proposal's semantics, as modeled in SsaWasm, match the eventual standardized behavior.
    Sections 4.4 and 6 rely on the early-stage stack switching proposal; correctness is only checked with wasmfxtime, not a formal conformance test.
  • domain assumption Polygeist-generated MLIR faithfully represents the PolyBench C benchmarks.
    Section 7.1 uses Polygeist to translate C to MLIR; the deriche benchmark is excluded due to Polygeist compilation issues, indicating a toolchain limitation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of WAMI: Compilation to WebAssembly through MLIR without Losing Abstraction." pith.science (2026). https://pith.science/paper/RDHBPZUN

@misc{pith2026250616048,
  author       = {Pith},
  title        = {Pith review of: WAMI: Compilation to WebAssembly through MLIR without Losing Abstraction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RDHBPZUN}},
  note         = {Machine review of arXiv:2506.16048}
}
read the original abstract

WebAssembly (Wasm) is a portable bytecode format that serves as a compilation target for high-level languages, enabling their secure and efficient execution across diverse platforms, including web browsers and embedded systems. To improve support for high-level languages without incurring significant code size or performance overheads, Wasm continuously evolves by integrating high-level features such as Garbage Collection and Stack Switching. However, existing compilation approaches either lack reusable design -- requiring redundant implementation efforts for each language -- or lose abstraction by lowering high-level constructs into low-level shared representations like LLVM IR, which hinder the adoption of high-level features. MLIR compiler infrastructure provides the compilation pipeline with multiple levels of abstraction, preserving high-level abstractions throughout the compilation pipeline, yet the current MLIR pipeline relies on the LLVM backend for Wasm code generation, thereby inheriting LLVM's limitations. This paper presents a novel compilation pipeline for Wasm, featuring Wasm dialects explicitly designed to represent high-level Wasm constructs within MLIR. Our approach enables direct generation of high-level Wasm code from corresponding high-level MLIR dialects without losing abstraction, providing a modular and extensible way to incorporate high-level Wasm features. We illustrate this extensibility through a case study that leverages Stack Switching, a recently introduced high-level feature of Wasm. Performance evaluations on PolyBench benchmarks show that our pipeline, benefiting from optimizations within the MLIR and Wasm ecosystems, produces code with at most 7.7\% slower, and faster in some execution environments, compared to LLVM-based compilers.

Figures

Figures reproduced from arXiv: 2506.16048 by the authors.

Figure 1
Figure 1. Overview of existing Wasm compilation pipelines. representations (IRs), high-level APIs that language frontends can target, and a set of optimization passes. However, because Binaryen is specialized for Wasm, it lacks the modularity and cross-target reusability found in general compiler frameworks like LLVM. As a result, languages using Binaryen inherit similar limitations to those built on custom compiler backends.… view at source ↗
Figure 2
Figure 2. Overview of WAMI To overcome the limitations associated with abstraction loss in LLVM and also leverage existing infrastructure for Wasm compilation, we propose WAMI, a novel, MLIR-based compiler pipeline for Wasm. WAMI introduces new MLIR dialects specifically designed to represent Wasm, which allows high-level MLIR dialects to be converted into Wasm without loss of abstractions [PITH_FULL_IMAGE:figures/full_fig_p… view at source ↗
Figure 3
Figure 3. SsaWasm Types and Operations 4.1 Summary of Types and Operations [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗
Figures from the paper (12 more)
Figure 5
Figure 5. Figure 5: A loop in Wasm and its MLIR representation in most cases, it is an unnecessarily complex component in compilers for high-level languages that do not have goto-style control flow. An alternative approach is to directly generate Wasm control flow from the high-level dial…
Figure 6
Figure 6. Figure 6: Example of Stack Switching instructions in Wasm control to it. The handler installed in the resume operation (on $yield $on_yield) redirects control to the suspend handler, which is $on_yield, if the continuation suspends with the $yield tag (e.g., suspend $yield in th…
Figure 7
Figure 7. Figure 7: The resume operation in SsaWasm 5 DIALECT CONVERSION PASSES In this section, we describe our conversion passes from core MLIR dialects to SsaWasm. After obtaining the SsaWasm dialect, we convert it to the Wasm dialect, which directly mirrors Wasm’s textual format, simp…
Figure 8
Figure 8. Figure 8: Examples of conversion from MemRef to SsaWasm memref-to-ssawasm. We support memory operations by providing dialect conversion from MemRef to SsaWasm. The memref.alloc and memref.dealloc, which allocates and deallocates heap memory, are converted to ssawasm.call @malloc…
Figure 9
Figure 9. Figure 9: Example of conversion from SCF to SsaWasm 1 %0 = ssawasm.const 1 : i32 2 %1 = ssawasm.const 2 : i32 3 %2 = ssawasm.add %0, %1 : i32 4 %3 = ssawasm.add %0, %2 : i32 (a) SsaWasm code without local variables. 1 wasm.block "block_label" { 2 wasm.loop "loop_label" { 3 ... 4…
Figure 10
Figure 10. Figure 10: Examples of conversion from SsaWasm to Wasm The ssawasm-to-wasm pass performs the dialect conversion from SsaWasm to the Wasm dialect by mapping each SsaWasm operation to a corresponding Wasm operation. Any operands [PITH_FULL_IMAGE:figures/full_fig_p015_10.png]
Figure 11
Figure 11. Figure 11: A simple generator example in the DCont dialect dcont.load, and dcont.store operations are converted to local variable declaration, load, and store operations, respectively. 1 dcont.resume %cont : (dcont.cont<(i32)->()>, i32) -> () 2 {(%val, %suspended_cont: i32, !dco…
Figure 12
Figure 12. Figure 12: Conversion of dcont.resume To support dialect conversion of dcont.resume, we introduce ssawasm.block_block to represent a nested structure block{ A block { B } C } similar to the ssawasm.block_loop operation [PITH_FULL_IMAGE:figures/full_fig_p017_12.png]
Figure 13
Figure 13. Figure 13: Compilation and execution pipelines for evaluation [PITH_FULL_IMAGE:figures/full_fig_p019_13.png]
Figure 14
Figure 14. Figure 14: Speedup of Wasm binaries produced by WAMI over LLVM across different runtimes and configurations. in MLIR, we inherit all general MLIR optimizations at no additional implementation cost; similarly, being within the Wasm ecosystem grants us access to Binaryen optimizat…
Figure 15
Figure 15. Figure 15: Comparison of Wasm code generated by the Wasm dialect-based compiler and LLVM. Moreover, applying LLVM optimizations may not always be optimal given that many Wasm runtimes can eventually apply machine-specific optimizations through JIT or AoT compilation. As a portab…
Figure 16
Figure 16. Figure 16: Speedup of WAMI-generated code over LLVM on the WAMR classic interpreter. 7.3 Summary Our evaluation highlights that, despite not implementing any optimization passes manually and not leveraging LLVM’s extensive optimization infrastructure, WAMI consistently generates…

Discussion (0). Sign in to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. The Program Hypergraph: Multi-Way Relational Structure for Geometric Algebra, Spatial Compute, and Physics-Aware Compilation

    cs.PL 2026-03 unverdicted novelty 7.0 of 10

    The Program Hypergraph extends binary program semantic graphs to arbitrary-arity hyperedges to faithfully represent multi-way relations in geometric algebra and spatial architectures.

  2. Dimensional Type Systems and Deterministic Memory Management: Design-Time Semantic Preservation in Native Compilation

    cs.PL 2026-03 unverdicted novelty 7.0 of 10

    Dimensional types that persist through MLIR lowering jointly drive numeric representation selection and deterministic memory allocation as coeffects on a single program semantic graph.

  3. Adaptive Domain Models: Bayesian Evolution, Warm Rotation, and Principled Training for Geometric and Neuromorphic AI

    cs.AI 2026-03 unverdicted novelty 6.0 of 10

    The paper claims that composing the Dimensional Type System, Program Hypergraph, and b-posit 2026 standard yields depth-independent training memory at ~2x inference, grade-preserving updates, Bayesian distillation for...

Reference graph

Works this paper leans on

68 extracted references · 65 canonical work pages · cited by 3 Pith papers

  1. [1]

    WebAssembly Core Specification

    2022. WebAssembly Core Specification. https://webassembly.github.io/spec/core/

    work page 2022

  2. [2]

    Emscripten: Asynchronous Code

    2015. Emscripten: Asynchronous Code. https://emscripten.org/docs/porting/asyncify.html Accessed: Mar 9, 2025

    work page 2015

  3. [3]

    An overview of the TurboFan compiler

    2016. An overview of the TurboFan compiler. https://docs.google.com/presentation/d/ 1H1lLsbclvzyOF3IUR05ZUaZcqDxo7_-8f4yJoxdMooU Accessed: Mar 18, 2025

    work page 2016

  4. [4]

    PolyBench/C 4.2.1

    2016. PolyBench/C 4.2.1. https://github.com/MatthiasJReisinger/PolyBenchC-4.2.1 Accessed: Feb 19, 2025

    work page 2016

  5. [5]

    Tensor Operator Set Architecture (TOSA) Dialect

    2021. Tensor Operator Set Architecture (TOSA) Dialect. https://mlir.llvm.org/docs/Dialects/TOSA/ Accessed: Mar 11, 2025

    work page 2021

  6. [6]

    Clang! Clang! Who’s there? WebAssembly

    2022. Clang! Clang! Who’s there? WebAssembly. https://llvm.org/devmtg/2022-11/slides/TechTalk3-ClangClang- WebAssembly.pdf Accessed: Mar 2, 2025

    work page 2022

  7. [7]

    Multiple Memories for Wasm

    2022. Multiple Memories for Wasm. https://github.com/WebAssembly/multi-memory/blob/main/proposals/multi- memory/Overview.md Accessed: Mar 11, 2025

    work page 2022

  8. [8]

    Pylir: An optimizing ahead-of-time Python Compiler

    2022. Pylir: An optimizing ahead-of-time Python Compiler. https://github.com/Pylir/Pylir Accessed: Feb 22, 2025

    work page 2022

Show all 68 references
  1. [9]

    Reference-Typed Strings

    2022. Reference-Typed Strings. https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview. md Accessed: Mar 11, 2025

    2022

  2. [10]

    Reference typing extensions for C++ (“Ref C++”)

    2022. Reference typing extensions for C++ (“Ref C++”). https://github.com/Igalia/ref-cpp Accessed: Mar 9, 2025

    2022

  3. [11]

    WebAssembly Micro Runtime

    2022. WebAssembly Micro Runtime. https://bytecodealliance.github.io/wamr.dev/ Accessed: Feb 22, 2025

    2022

  4. [12]

    Cranelift

    2023. Cranelift. https://cranelift.dev/ Accessed: Mar 24, 2025

    2023

  5. [13]

    Getting Started for J2CL/Wasm (Experimental)

    2023. Getting Started for J2CL/Wasm (Experimental). https://github.com/google/j2cl/blob/ b3ff9e233cef3e67e495476da14f13250a56c5e9/docs/getting-started-j2wasm.md Accessed: Mar 8, 2025

    2023

  6. [14]

    ‘memref’ Dialect

    2023. ‘memref’ Dialect. https://mlir.llvm.org/docs/Dialects/MemRef/ Accessed: Mar 11, 2025

    2023

  7. [15]

    Multi-Level Intermediate Representation Overview

    2023. Multi-Level Intermediate Representation Overview. https://mlir.llvm.org/ Accessed: Mar 25, 2025

    2023

  8. [16]

    ‘cf’ Dialect

    2024. ‘cf’ Dialect. https://mlir.llvm.org/docs/Dialects/ControlFlowDialect/ Accessed: Mar 11, 2025

    2024

  9. [17]

    Dart/Wasm

    2024. Dart/Wasm. https://dart.dev/web/wasm Accessed: Mar 8, 2025

    2024

  10. [18]

    GHC: The Glasgow Haskell Compiler

    2024. GHC: The Glasgow Haskell Compiler. https://www.haskell.org/ghc/ Accessed: Feb 22, 2025

    2024

  11. [19]

    Go Wiki: WebAssembly

    2024. Go Wiki: WebAssembly. https://go.dev/wiki/WebAssembly Accessed: Feb 22, 2025

    2024

  12. [20]

    2024. Grain. https://grain-lang.org/ Accessed: Feb 22, 2025

    2024

  13. [21]

    JSIR: Adversarial JavaScript Analysis with MLIR

    2024. JSIR: Adversarial JavaScript Analysis with MLIR. https://llvm.org/devmtg/2024-10/slides/techtalk/Tan-JSIR.pdf Accessed: Mar 24, 2025

    2024

  14. [22]

    Kotlin/Wasm

    2024. Kotlin/Wasm. https://kotlinlang.org/docs/wasm-overview.html Accessed: Mar 8, 2025

    2024

  15. [23]

    MLIR: Side Effects and Speculation

    2024. MLIR: Side Effects and Speculation. https://mlir.llvm.org/docs/Rationale/SideEffectsAndSpeculation/ Accessed: Mar 11, 2025

    2024

  16. [24]

    Threading proposal for WebAssembly

    2024. Threading proposal for WebAssembly. https://github.com/WebAssembly/threads/blob/main/proposals/threads/ Overview.md Accessed: Mar 11, 2025

    2024

  17. [25]

    Wasmtime: A fast and secure runtime for WebAssembly

    2024. Wasmtime: A fast and secure runtime for WebAssembly. https://wasmtime.dev/ Accessed: Mar 24, 2025

    2024

  18. [26]

    ‘arith’ Dialect

    2025. ‘arith’ Dialect. https://mlir.llvm.org/docs/Dialects/ArithOps/ Accessed: Mar 11, 2025

    2025

  19. [27]

    AssemblyScript

    2025. AssemblyScript. https://www.assemblyscript.org/ Accessed: Feb 22, 2025

    2025

  20. [28]

    Attribute specifier sequence

    2025. Attribute specifier sequence. https://en.cppreference.com/w/cpp/language/attributes Accessed: Mar 9, 2025

    2025

  21. [29]

    Binaryen

    2025. Binaryen. https://github.com/WebAssembly/binaryen Accessed: Feb 22, 2025

    2025

  22. [30]

    Build WAMR vmcore

    2025. Build WAMR vmcore. https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/doc/build_wamr.md Accessed: Mar 24, 2025

    2025

  23. [31]

    C++ Coroutines

    2025. C++ Coroutines. https://en.cppreference.com/w/cpp/language/coroutines Accessed: Mar 9, 2025

    2025

  24. [32]

    2025. ClangIR. https://llvm.github.io/clangir/ Accessed: Mar 18, 2025

    2025

  25. [33]

    Coroutines in LLVM

    2025. Coroutines in LLVM. https://llvm.org/docs/Coroutines.html Accessed: Mar 9, 2025

    2025

  26. [34]

    Exception handling

    2025. Exception handling. https://github.com/WebAssembly/exception-handling/blob/main/proposals/exception- handling/Exceptions.md Accessed: Mar 11, 2025

    2025

  27. [35]

    Extending LLVM

    2025. Extending LLVM. https://llvm.org/docs/ExtendingLLVM.html Accessed: Mar 2, 2025

    2025

  28. [36]

    ‘gpu’ Dialect

    2025. ‘gpu’ Dialect. https://mlir.llvm.org/docs/Dialects/GPU/ Accessed: Mar 25, 2025

    2025

  29. [37]

    ‘linalg’ Dialect

    2025. ‘linalg’ Dialect. https://mlir.llvm.org/docs/Dialects/Linalg/ Accessed: Mar 11, 2025

    2025

  30. [38]

    Marco: Modelica Advanced Research COmpiler

    2025. Marco: Modelica Advanced Research COmpiler. https://github.com/marco-compiler/marco Accessed: Feb 22, 2025

    2025

  31. [39]

    2025. Mojo. https://www.modular.com/mojo Accessed: Feb 22, 2025. WAMI: Compilation to WebAssembly through MLIR without Losing Abstraction 25

    2025

  32. [40]

    ‘scf’ Dialect

    2025. ‘scf’ Dialect. https://mlir.llvm.org/docs/Dialects/SCFDialect/ Accessed: Mar 11, 2025

    2025

  33. [41]

    Stack switching

    2025. Stack switching. https://github.com/WebAssembly/stack-switching/blob/main/proposals/stack-switching/ Explainer.md Accessed: Mar 11, 2025

    2025

  34. [42]

    TableGen Overview

    2025. TableGen Overview. https://llvm.org/docs/TableGen/ Accessed: Mar 24, 2025

    2025

  35. [43]

    ‘vector’ Dialect

    2025. ‘vector’ Dialect. https://mlir.llvm.org/docs/Dialects/Vector/ Accessed: Mar 25, 2025

    2025

  36. [44]

    wasmfxtime

    2025. wasmfxtime. https://github.com/wasmfx/wasmfxtime Accessed: Mar 20, 2025

    2025

  37. [45]

    WebAssembly Proposals

    2025. WebAssembly Proposals. https://github.com/WebAssembly/proposals Accessed: Mar 9, 2025

    2025

  38. [46]

    WebAssembly Security

    2025. WebAssembly Security. https://webassembly.org/docs/security/ Accessed: Mar 9, 2025

    2025

  39. [47]

    The Zephyr Project

    2025. The Zephyr Project. https://docs.zephyrproject.org/latest/ Accessed: Feb 19, 2025

    2025

  40. [48]

    Léo Andrès, Pierre Chambart, and Jean-Christophe Filliâtre. 2023. Wasocaml: compiling OCaml to WebAssembly. (2023)

    2023

  41. [49]

    Aart Bik, Penporn Koanantakool, Tatiana Shpeisman, Nicolas Vasilache, Bixia Zheng, and Fredrik Kjolstad. 2022. Compiler support for sparse tensor computations in MLIR. ACM Transactions on Architecture and Code Optimization (TACO) 19, 4 (2022), 1–25

    2022

  42. [50]

    Nick Brown. 2024. Fully integrating the Flang Fortran compiler with standard MLIR. In SC24-W: Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis . IEEE, 939–949

    2024

  43. [51]

    Keith D Cooper, L Taylor Simpson, and Christopher A Vick. 2001. Operator strength reduction. ACM Transactions on Programming Languages and Systems (TOPLAS) 23, 5 (2001), 603–625

    2001

  44. [52]

    Mattias Felleisen. 1988. The theory and practice of first-class prompts. InProceedings of the 15th ACM SIGPLAN-SIGACT symposium on Principles of programming languages . 180–190

    1988

  45. [53]

    Renato Golin, Lorenzo Chelini, Adam Siemieniuk, Kavitha Madhu, Niranjan Hasabnis, Hans Pabst, Evangelos Geor- ganas, and Alexander Heinecke. 2024. Towards a high-performance AI compiler with upstream MLIR. arXiv preprint arXiv:2404.15204 (2024)

    2024 arXiv

  46. [54]

    Andreas Haas, Andreas Rossberg, Derek L Schuff, Ben L Titzer, Michael Holman, Dan Gohman, Luke Wagner, Alon Zakai, and JF Bastien. 2017. Bringing the web up to speed with WebAssembly. InProceedings of the 38th ACM SIGPLAN conference on programming language design and implement...

    2017

  47. [55]

    Tian Jin, Gheorghe-Teodor Bercea, Tung D Le, Tong Chen, Gong Su, Haruki Imai, Yasushi Negishi, Anh Leu, Kevin O’Brien, Kiyokuni Kawachiya, et al . 2020. Compiling onnx neural network models using mlir. arXiv preprint arXiv:2008.08272 (2020)

    2020 arXiv

  48. [56]

    Chris Lattner and Vikram Adve. 2004. LLVM: A compilation framework for lifelong program analysis & transformation. In International symposium on code generation and optimization, 2004. CGO 2004. IEEE, 75–86

    2004

  49. [57]

    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. In 2021 IEEE/ACM International Sympos...

    2021

  50. [58]

    Andrew Lenharth and Chris Lattner. 2021. CIRCT: Lifting hardware development out of the 20th century. https: //llvm.org/devmtg/2021-11/slides/2021-CIRCT-LiftingHardwareDevOutOfThe20thCentury.pdf Accessed: Mar 25, 2025

    2021

  51. [60]

    Martin Lücke, Michel Steuwer, and Aaron Smith. 2021. Integrating a functional pattern-based IR into MLIR. In Proceedings of the 30th ACM SIGPLAN International Conference on Compiler Construction . 12–22

    2021

  52. [61]

    William S Moses, Lorenzo Chelini, Ruizhe Zhao, and Oleksandr Zinenko. 2021. Polygeist: Raising C to polyhedral MLIR. In 2021 30th International Conference on Parallel Architectures and Compilation Techniques (PACT) . IEEE, 45–59

    2021

  53. [62]

    Jacques Pienaar et al. 2020. Mlir in tensorflow ecosystem. In compilers For Machine Learning (C4ML) 2020

    2020

  54. [63]

    Norman Ramsey. 2022. Beyond Relooper: recursive translation of unstructured control flow to structured control flow (functional pearl). Proceedings of the ACM on Programming Languages 6, ICFP (2022), 1–22

    2022

  55. [64]

    Jim M. R. Teichgräber. 2023. Efficient Compilation of an Extensible Intermediate Representation. https://github.com/J- MR-T/MoNaCo

    2023

  56. [65]

    Philippe Tillet, Hsiang-Tsung Kung, and David Cox. 2019. Triton: an intermediate language and compiler for tiled neural network computations. In Proceedings of the 3rd ACM SIGPLAN International Workshop on Machine Learning and Programming Languages. 10–19

    2019

  57. [66]

    Vinay/Ranjith/Prashantha. 2021. Moving LLVM’s code generator to MLIR framework. https://llvm.org/devmtg/2021- 02-28/slides/Vinay-MLIR-codegen.pdf

    2021

  58. [67]

    Jun Xu, Liang He, Xin Wang, Wenyong Huang, and Ning Wang. 2021. A fast WebAssembly Interpreter design in W ASM-Micro-Runtime. Technical Report. https://www.intel.com/content/www/us/en/developer/articles/technical/ webassembly-interpreter-design-wasm-micro-runtime.html Accessed...

    2021

  59. [68]

    Alon Zakai. 2011. Emscripten: an LLVM-to-JavaScript compiler. In Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion . 301–312

    2011

  60. [69]

    Kai Zhu, WY Zhao, Zhen Zheng, TY Guo, PZ Zhao, JJ Bai, Jun Yang, XY Liu, LS Diao, and Wei Lin. 2021. DISC: A dynamic shape compiler for machine learning workloads. In Proceedings of the 1st Workshop on Machine Learning and Systems. 89–95

    2021

Pith tools

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