Pith. sign in

REVIEW 4 major objections 5 minor 84 references

LEGO-Compiler: Enhancing Neural Compilation Through Translation Composability

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 A split-translate-reassemble pipeline lets LLMs compile C to assembly at over 99% accuracy and roughly ten times the code size.

desk verdict A solid, honest systems paper where 'correctly compile' really means 'pass 10 unit tests'; the decomposition workflow is a genuine advance, but the formal composability proofs are sketches and no artifacts are released. read the letter →

arxiv 2505.20356 v1 pith:YXMVJBWO submitted 2025-05-26 cs.PL cs.AIcs.SE

Shuoming Zhang , Jiacheng Zhao , Chunwei Xia , Zheng Wang , Yunji Chen , Xiaobing Feng , Huimin Cui This is my paper · ORCID
classification cs.PLcs.AIcs.SE
keywords neuralcompilationLLMcodetranslationprogramdecompositioncomposabilitycontrol-flowblocksassemblygenerationself-correctionsizescalability
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

LEGO-Compiler claims that the reason LLMs fail at compiling C to assembly is not raw context length but the loss of structure, and that splitting a function into control blocks, translating each block with a shared symbol table and stack-frame mapping, and reassembling them restores both accuracy and scalability. On a large executable-C benchmark the paper reports over 99% of functions passing all supplied tests, and 97.9% on a collection of real-world ANSI C benchmarks; it also compiles functions roughly ten times larger than direct end-to-end translation can handle. The load-bearing idea is translation composability: if each block's translation is semantically preserving, then concatenating those translations with the right jump instructions preserves the whole program's control and data flow, which the paper proves for a structured C-like language and tests on x86, arm64, and riscv64. If true, this means large parts of a compiler front-end can be delegated to LLMs without a training corpus of compiler-generated code, at the price of very high compute.

What carries the argument

LEGO translation, the named method that carries the argument. A C function is decomposed by an LLM-guided algorithm into composable control blocks (basic blocks and innermost loops, conditionals, and switches), each block is translated into assembly in isolation while sharing one symbol table, stack offsets, and ABI conventions, and the partial assemblies are concatenated with jump instructions into the final function. The formal part supplies the identity that makes this safe: for blocks $P_1$, $P_2$, a semantics-preserving translation satisfies $T(P_1 \circ P_2) \equiv T(P_1) \cdot T(P_2)$, with $\equiv$ meaning both control and data flow are preserved; the workflow part makes it practical by verifying intermediate stages (renamed source, layouts, allocation plan, CFG isomorphism) and by feeding assembler, runtime, and test errors back into the LLM.

What would settle it

Take a random sample of the functions LEGO-Compiler passes and run the generated assembly against many more inputs than the supplied ten, for instance generated random inputs or a differential comparison with the oracle-compiled executable; any mismatch on an input where the C source succeeds would show that block-composed translations are not semantically equivalent for all inputs.

Watch

Extended reading notes

Core claim

The central discovery is that neural translation is composable at the control-block level: a correct translation of each basic block or control structure, together with a consistent symbol table and stack layout, can be spliced into a correct whole, because assembly code is linearized and the block boundaries correspond to jumps and labels. The paper formalizes this as a translation function $T$ with $T(P_1 \circ P_2) \equiv T(P_1) \cdot T(P_2)$, proves it for basic statements, loops, conditionals, switches, break/continue, and sequential control blocks, and builds a workflow around it: variable renaming, type/layout analysis, variable mapping, LLM-driven block splitting, per-block translation, reassembly, and test-feedback self-correction. Empirically this lifts success on the main benchmark from roughly 88-95% for direct translation to 97.7-99.7% across models, and pushes compilable code size from around a few hundred tokens to the scale of a 2.6k-token industrial main function.

Load-bearing premise

The evaluation calls a translation correct if it passes the ten input/output test cases supplied for that function, and the proof assumes each independently translated block preserves semantics for all inputs; if independently correct blocks stop agreeing when joined over a shared stack frame on inputs outside the test suite, the headline accuracy and scalability do not generalize.

Editorial extensions

If this is right

  • The reported gains are not model-specific: on the main benchmark, every model tested improves from roughly 88-95% direct accuracy to 97.7-99.7% with the full pipeline.
  • Compiling a function the size of CoreMark's main function, around 200 lines and 2.6k tokens, becomes achievable where direct translation with advanced LLMs fails, extending neural compilation by roughly an order of magnitude in code size.
  • The same workflow ports to arm64 and riscv64 with similar relative improvements, although absolute accuracy is lower because the models have less pretraining knowledge of those instruction sets.
  • Self-correction using assembler, runtime, and unit-test feedback repairs most residual errors, especially wrong operand forms and incorrect addressing of global variables.
  • Because the approach needs no compiler-generated bilingual corpus, it is training-free and model-agnostic, so the same prompts and workflow can absorb future LLMs as they improve.

Reading between the lines

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

  • The composability principle is not tied to assembly; the same split-translate-rebuild recipe should apply to source-to-source transpilation for structured languages, which the paper notes but does not evaluate.
  • The accuracy definition matters: 'correct' here means passing the ten provided IO tests, so the system could still emit assembly that differs behaviorally on untested inputs; a stronger evaluation with differential or random-input testing would clarify how close the reported percentages are to true semantic equivalence.
  • If the approach scales to whole repositories, the practical niche is not replacing optimizing compilers but fast bring-up of new targets and instruction extensions, since the paper notes the compute cost is roughly 10^6-10^7 times higher than traditional compilation.
  • A sharp testable boundary follows from the proof: code with arbitrary goto or unstructured control flow should break LEGO composability, so measuring accuracy on such code would directly probe the proof's scope.
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 LEGO-Compiler, a training-free LLM pipeline for translating C functions into assembly. The pipeline decomposes a function into control-flow blocks, maintains a shared symbol table, translates blocks independently, concatenates the block-level assembly, and verifies the final executable against ten IO test cases per function, with up to five self-correction rounds. The authors report over 99% accuracy on a cleaned 17,121-case ExeBench subset, 97.9% on AnsiBench, and roughly an order-of-magnitude improvement in the size of code that can be compiled, and they provide a formal argument in Appendix A that structured C-like programs are composable under semantics-preserving translations.

Significance. If the claims are taken at face value, this is a useful result for neural compilation and for LLM-driven divide-and-conquer translation: it shows across eight models and three ISAs that a verifiable workflow plus block decomposition improves over direct translation, and the Csmith and AnsiBench results are consistent with a genuine scalability benefit. Strengths include the use of external benchmarks, which avoids circularity in the main empirical result, a model-independent evaluation protocol, multi-model and multi-architecture ablations, and an explicit attempt to formalize translation composability. The principal caveat is that "correctly compile" is operationalized as passing ten fixed IO tests after up to five repair attempts, so the absolute accuracy numbers are test-set pass rates, not established semantic correctness.

major comments (4)
  1. [§4.2, steps 3–5] The headline claim "correctly compile over 99% of ExeBench" is defined as passing the ten IO test cases provided by ExeBench after up to k=5 self-correction attempts. Ten IO cases cannot certify semantic equivalence, and the same weak oracle is used for all compared methods and for the scalability claims in Sections 4.3–4.4. Please rephrase all accuracy claims as "passes the provided 10 IO tests after up to five repair attempts," report Pass@1 and Pass@5 separately, and/or add differential testing on additional random inputs; otherwise the abstract and Section 4.2 overstate what is measured.
  2. [Appendix A, Definitions 7–8 and Theorems 2/4] The formal composability argument postulates a translation function T that is semantics-preserving for every statement, and then proves that concatenating such ideal block translations with "appropriate jump instructions" preserves control and data flow. The LEGO-Compiler workflow is never shown to produce such per-block T translations; only the final assembly is checked against the ten IO tests. The proof therefore does not close the gap between the ideal composability theorem and the empirical pipeline. Please add per-block verification or a precise statement of the conditions (jump labels, stack and register conventions, symbol-table consistency, prologue/epilogue placement) under which the composed translation is equivalent, and explain how the workflow enforces them.
  3. [§4.3–§4.4, Figures 3 and 8] The "near an order-of-magnitude improvement on compilable code size" claim is not backed by a defined metric. Figures 3 and 8 report token counts and instruction counts for cases passed by different methods, but they do not compute, for example, the maximum code size at which each method succeeds with a fixed success probability; they also do not report confidence intervals. The Csmith comparison is based on only 40 randomly generated programs (25 vs 4 vs 13), and Section C.2 indicates that baseline failures are partly due to output truncation, which is a generation-length artifact rather than a semantic scalability measure. Please define compilable code size precisely and report error bars.
  4. [Table 1] Table 1 compares the direct-translation rows with the prior result from Zhang et al. [63] (91.718%), but the manuscript does not state whether the prior-work number uses the same 10-IO oracle, the same cleaned ExeBench split, the same self-correction budget, and the same pass definition. If the prior row is Pass@1 without self-correction, the comparison is not apples-to-apples. Please specify the exact protocol used for the prior-work row and for every other row.
minor comments (5)
  1. [Throughout] There are multiple typos that should be fixed: "acheived" in the abstract, "demosntrating" in the conclusion, "aribitrary" in Theorem 6, "peformance" in Section 4.3, and "hundreads" in Section C.2.
  2. [Definition 1] The text says "unary relation ⇀" but a relation from Lsrc to Ldst is binary; please correct the terminology or clarify the intended notation.
  3. [Figure 1(a)] The plain-translation example in Figure 1(a) is a C-to-Python translation, which is not the compilation task addressed by the paper; using a C-to-x86 example in both panels would make the figure more directly relevant.
  4. [References] Reference [17] contains the placeholder "Accessed: [Insert access date here]" and reference [32] lacks publication details and a year; these should be completed.
  5. [Table 4] Table 4 uses models not present in Tables 1–3 (GPT-4o, Claude-3-Haiku) and does not explain how Pass@5 is computed; please clarify whether these are supplementary models and whether the pass metric is over independent samples or over self-correction attempts.

Circularity Check

3 steps flagged · score 5.0 of 10

The empirical ExeBench/AnsiBench claims are externally benchmarked and not circular, but the Appendix A formal composability proof is partly definitional: Theorem 4 restates Definition 9, Theorem 1 assumes the independence it must prove, and Theorem 2 postulates the 'appropriate jump instructions' that are the LEGO reassembly claim.

  1. other [Appendix A.2, Theorem 1 proof, Example A.1]
    "Independence: The translation of stmt_2 does not depend on how stmt_1 was translated, only on its effect (the value of 'a'). Therefore,T(stmt 1 ◦stmt 2)≡T(stmt 1)·T(stmt 2), demonstrating composability."

    The theorem must establish that independently produced per-statement translations can be concatenated without conflicts over locations, registers, or labels. That non-interference property is exactly the composability claim, yet the proof simply asserts it in the 'Independence' bullet and then writes the theorem's equation. Definition 7 only requires that T(stmt) preserve semantics as a standalone statement; it does not imply that two such translations agree on the mapping of 'a' or on other shared state. The example even contains a data dependency (stmt1 writes 'a', stmt2 reads it) and stipulates that the dependency is preserved. The derivation therefore reduces to the conclusion it is supposed to prove.

  2. other [Appendix A.3, Theorem 2, For Loop proof]
    "3. Composability: T(basic_f or_loop)≡T(B init)·T(B cond)·T(B body)·T(B incr), where · represents concatenation with appropriate jump instructions."

    The LEGO part-rebuild step consists of joining independently translated blocks with correct branch targets, fall-throughs, and loop labels. Those 'appropriate jump instructions' are precisely what must be shown to exist and be correct; the proof does not construct them from the per-block translations or derive their correctness. It simply asserts that the composite is equivalent because the block translations are concatenated in source order. The same pattern is repeated for if-else, while, do-while, and switch, so the composability of basic control structures is assumed rather than established.

1 more flagged steps
  1. self definitional [Appendix A.4, Definition 9 and Theorem 4]
    "Definition 9 (Composable Control Block). A composable control block is either: ... A sequence of composable control blocks, or ... Theorem 4 (Composability of Sequential Control Blocks). A sequence of composable control blocks CB 1, CB2, ..., CBn as defined in Definition 9 is composable under the translation functionT."

    Definition 9 already includes 'A sequence of composable control blocks' as one of the clauses defining a composable control block. Theorem 4 then 'proves' that a sequence of composable control blocks is composable, which is an immediate instance of the definition rather than a derived result. As a proof step, it contributes no independent evidence that independent LLM block translations can be reassembled; the sequential-composability conclusion is true by construction of the definition.

full rationale

The empirical core is not circular: the headline numbers (99.375% on ExeBench, 97.9% on AnsiBench, the Csmith/AnsiBench scalability ablations) come from translating, assembling, linking, and executing against external benchmark oracles, so the accuracy results have independent content. The one self-citation, [63], is used as a comparative baseline rather than as load-bearing justification, and the LEGO-Prover inspiration [52] is not by these authors. The circularity burden is confined to the theoretical framing: Appendix A's composability proof is partly definitional (Theorem 4 restates Definition 9) and partly question-begging (Theorem 1's 'Independence' premise and Theorem 2's 'appropriate jump instructions' assume the reassembly correctness that is the very claim). In addition, Section 4.2 defines a translation as successful only if it passes ExeBench's 10 provided IO test cases, so the 99% figure is a pass-all-10-tests metric rather than demonstrated semantic equivalence; that is a correctness/generalization caveat, not circularity, and it is noted separately. Because the central benchmark claims are independent while a supporting formal result is definitional in places, the overall circularity score is moderate.

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

The central claim rests on a small number of explicit evaluation choices (retry budget, subset thresholds, temperature) and on four domain assumptions: the existence of semantics-preserving block translations, the safety of concatenating such translations, the sufficiency of 10 unit tests as a correctness oracle, and the representativeness of the simplified grammar. No new physical or mathematical entities are postulated, so the invented-entities ledger is empty.

free parameters (3)
  • Self-correction rounds k = 5
    The reported accuracy depends on allowing up to 5 repair attempts; without this retry budget, accuracy would be lower. This is a hand-chosen evaluation parameter affecting the headline numbers.
  • Hard subset thresholds = BB count >= 10 OR max instructions in BB >= 80 OR total instructions >= 200
    These thresholds define the 'hard' ExeBench subset used for architecture and model comparisons; different thresholds would change the reported hard-subset accuracy.
  • Temperature = not reported (0.0-1.0 tested)
    The paper tests temperatures from 0.0 to 1.0 but does not state which value was used for the main results in Tables 1 to 3, leaving an unspecified configuration parameter.
assumptions (4)
  • domain assumption There exists a translation function T that preserves semantics for each statement and block (Definition 7).
    The composability proofs begin from this definition; the existence of such T for arbitrary blocks is exactly what the LLM workflow must deliver, and the paper does not prove it.
  • ad hoc to paper Concatenation of valid translations of adjacent blocks in the target assembly yields a valid translation of the concatenated source.
    This is the load-bearing composition property assumed in Theorems 2, 4, and 5; the proof asserts it with 'appropriate jump instructions' but does not formalize register, memory, stack, or label-collision effects.
  • domain assumption Passing the 10 provided IO tests per ExeBench function is a sufficient behavioral oracle for correctness.
    Section 4.2 defines success purely as passing all test cases; the paper then reports this as 'correctly compile' over 99% of ExeBench.
  • domain assumption The simplified C-like grammar in Appendix A is representative of real C functions for the proof's conclusions.
    Appendix A initially excludes goto, and the limitations section acknowledges exceptions, coroutines, reflection, and unstructured control flow; the proof's validity for arbitrary real C functions is assumed.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LEGO-Compiler: Enhancing Neural Compilation Through Translation Composability." pith.science (2026). https://pith.science/paper/YXMVJBWO

@misc{pith2026250520356,
  author       = {Pith},
  title        = {Pith review of: LEGO-Compiler: Enhancing Neural Compilation Through Translation Composability},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YXMVJBWO}},
  note         = {Machine review of arXiv:2505.20356}
}
read the original abstract

Large language models (LLMs) have the potential to revolutionize how we design and implement compilers and code translation tools. However, existing LLMs struggle to handle long and complex programs. We introduce LEGO-Compiler, a novel neural compilation system that leverages LLMs to translate high-level languages into assembly code. Our approach centers on three key innovations: LEGO translation, which decomposes the input program into manageable blocks; breaking down the complex compilation process into smaller, simpler verifiable steps by organizing it as a verifiable LLM workflow by external tests; and a feedback mechanism for self-correction. Supported by formal proofs of translation composability, LEGO-Compiler demonstrates high accuracy on multiple datasets, including over 99% on ExeBench and 97.9% on industrial-grade AnsiBench. Additionally, LEGO-Compiler has also acheived near one order-of-magnitude improvement on compilable code size scalability. This work opens new avenues for applying LLMs to system-level tasks, complementing traditional compiler technologies.

Figures

Figures reproduced from arXiv: 2505.20356 by the authors.

Figure 1
Figure 1. a. Plain translation vs LEGO translation, by splitting the program into smaller composable control blocks(parts), translating each part becomes an easier task, and rebuilding each translated partial result will form a full translation. b. LEGO compiler, a special case for LEGO translation, to translate each part correctly, a symbol table needs to be maintained first and provided during translation. 3 Methods 3.1 Pro… view at source ↗
Figure 2
Figure 2. Neural compilation workflow in LEGO-Compiler. Left figure shows the behavioral verification process with unit-tests. Right figure shows the detailed steps in the workflow, some step is residual that may be skipped as performing such step may be unnecessary for certain input program. • Symbol Handling: Accurate translation necessitates careful management of symbols (like variable scopes, types, and memory locations) … view at source ↗
Figure 3
Figure 3. AnsiBench evaluation results with Claude-3.7-Sonnet. The [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Example workflow for LEGO-Compiler on a full ExeBench example: source code anal [PITH_FULL_IMAGE:figures/full_fig_p024_4.png]
Figure 5
Figure 5. Figure 5: Complexity breakdown of ExeBench and its hard 10% (roughly) subset, we use llvm as the [PITH_FULL_IMAGE:figures/full_fig_p026_5.png]
Figure 6
Figure 6. Figure 6: The CoreMark main function, one of the most difficult code we evaluated. In this figure, all [PITH_FULL_IMAGE:figures/full_fig_p027_6.png]
Figure 7
Figure 7. Figure 7: Csmith example code, the major body part of the right hand side code is omitted. This [PITH_FULL_IMAGE:figures/full_fig_p028_7.png]
Figure 8
Figure 8. Figure 8: Csmith random generated code statistics, where the practical utility of the LEGO method is [PITH_FULL_IMAGE:figures/full_fig_p029_8.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

84 extracted references · 65 canonical work pages

  1. [63]

    Introducing compiler semantics into large language models as programming language translators: A case study of C to x86 assembly

    Shuoming Zhang, Jiacheng Zhao, Chunwei Xia, Zheng Wang, Yunji Chen, and Huimin Cui. Introducing compiler semantics into large language models as programming language translators: A case study of C to x86 assembly. In Yaser Al-Onaizan, Mohit Bansal, and Yun-Nung Chen, editors,Findings of the Association for Computational Linguistics: EMNLP 2024, pages 996–...

    work page 2024

  2. [1]

    Claude ai.https://www.anthropic.com, 2023

    Anthropic. Claude ai.https://www.anthropic.com, 2023. Accessed: 2024-09-14

    2023

  3. [2]

    Claude 3.7 sonnet and claude code

    Anthropic. Claude 3.7 sonnet and claude code. https://www.anthropic.com/news/ claude-3-7-sonnet, February 2025. Accessed: 2025-05-04

    2025

  4. [3]

    Learning c to x86 translation: An experiment in neural compilation.arXiv preprint arXiv:2108.07639, 2021

    Jordi Armengol-Estapé and Michael FP O’Boyle. Learning c to x86 translation: An experiment in neural compilation.arXiv preprint arXiv:2108.07639, 2021

    arXiv 2021

  5. [4]

    Exebench: an ml-scale dataset of executable c functions

    Jordi Armengol-Estapé, Jackson Woodruff, Alexander Brauckmann, José Wesley de Souza Magalhães, and Michael FP O’Boyle. Exebench: an ml-scale dataset of executable c functions. InProceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming, pages 50–59, 2022

    2022

  6. [5]

    Slade: A portable small language model decompiler for optimized assembler.arXiv preprint arXiv:2305.12520, 2023

    Jordi Armengol-Estapé, Jackson Woodruff, Chris Cummins, and Michael FP O’Boyle. Slade: A portable small language model decompiler for optimized assembler.arXiv preprint arXiv:2305.12520, 2023

    arXiv 2023

  7. [6]

    Boosting neural networks to decom- pile optimized binaries

    Ying Cao, Ruigang Liang, Kai Chen, and Peiwei Hu. Boosting neural networks to decom- pile optimized binaries. InProceedings of the 38th Annual Computer Security Applications Conference, pages 508–518, 2022

    2022

  8. [7]

    Divide-and-conquer meets consensus: Unleashing the power of functions in code generation

    Jingchang Chen, Hongxuan Tang, Zheng Chu, Qianglong Chen, Zekun Wang, Ming Liu, and Bing Qin. Divide-and-conquer meets consensus: Unleashing the power of functions in code generation. InThe Thirty-eighth Annual Conference on Neural Information Processing Systems, 2024

    2024

Show all 84 references
  1. [8]

    Navigate through enigmatic labyrinth a survey of chain of thought reasoning: Advances, frontiers and future, 2024

    Zheng Chu, Jingchang Chen, Qianglong Chen, Weijiang Yu, Tao He, Haotian Wang, Weihua Peng, Ming Liu, Bing Qin, and Ting Liu. Navigate through enigmatic labyrinth a survey of chain of thought reasoning: Advances, frontiers and future, 2024

    2024

  2. [9]

    Large language models for compiler optimization.arXiv preprint arXiv:2309.07062, 2023

    Chris Cummins, V olker Seeker, Dejan Grubisic, Mostafa Elhoushi, Youwei Liang, Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Kim Hazelwood, Gabriel Synnaeve, et al. Large language models for compiler optimization.arXiv preprint arXiv:2309.07062, 2023. 10

    2023 arXiv

  3. [10]

    Meta large language model compiler: Foundation models of compiler optimization, 2024

    Chris Cummins, V olker Seeker, Dejan Grubisic, Baptiste Roziere, Jonas Gehring, Gabriel Synnaeve, and Hugh Leather. Meta large language model compiler: Foundation models of compiler optimization, 2024

    2024

  4. [11]

    Z3: An Efficient SMT Solver

    Leonardo de Moura and Nikolaj Bjørner. Z3: An Efficient SMT Solver. In C. R. Ramakrishnan and Jakob Rehof, editors,Tools and Algorithms for the Construction and Analysis of Systems, volume 4963 ofLecture Notes in Computer Science, pages 337–340, Berlin, Heidelberg, 2008. Sprin...

    2008

  5. [12]

    Deepseek-v3 technical report, 2024

    DeepSeek-AI. Deepseek-v3 technical report, 2024

    2024

  6. [13]

    A survey on in-context learning, 2024

    Qingxiu Dong, Lei Li, Damai Dai, Ce Zheng, Jingyuan Ma, Rui Li, Heming Xia, Jingjing Xu, Zhiyong Wu, Baobao Chang, Xu Sun, Lei Li, and Zhifang Sui. A survey on in-context learning, 2024

    2024

  7. [14]

    The linpack benchmark: past, present and future.Concurrency and Computation: practice and experience, 15(9):803–820, 2003

    Jack J Dongarra, Piotr Luszczek, and Antoine Petitet. The linpack benchmark: past, present and future.Concurrency and Computation: practice and experience, 15(9):803–820, 2003

    2003

  8. [15]

    What’s wrong with your code generated by large language models? an extensive study, 2024

    Shihan Dou, Haoxiang Jia, Shenxi Wu, Huiyuan Zheng, Weikang Zhou, Muling Wu, Mingxu Chai, Jessica Fan, Caishuang Huang, Yunbo Tao, Yan Liu, Enyu Zhou, Ming Zhang, Yuhao Zhou, Yueming Wu, Rui Zheng, Ming Wen, Rongxiang Weng, Jingang Wang, Xunliang Cai, Tao Gui, Xipeng Qiu, Qi Z...

    2024

  9. [16]

    Codebert: A pre-trained model for programming and natural languages, 2020

    Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. Codebert: A pre-trained model for programming and natural languages, 2020

    2020

  10. [17]

    GNU Binutils, 2023

    Free Software Foundation.c++filt. GNU Binutils, 2023. Accessed: [Insert access date here]

    2023

  11. [18]

    Coda: An end-to-end neural program decompiler.Advances in Neural Information Processing Systems, 32, 2019

    Cheng Fu, Huili Chen, Haolan Liu, Xinyun Chen, Yuandong Tian, Farinaz Koushanfar, and Jishen Zhao. Coda: An end-to-end neural program decompiler.Advances in Neural Information Processing Systems, 32, 2019

    2019

  12. [19]

    Exploring coremark a benchmark maximizing simplicity and efficacy.The Embedded Microprocessor Benchmark Consortium, 2012

    Shay Gal-On and Markus Levy. Exploring coremark a benchmark maximizing simplicity and efficacy.The Embedded Microprocessor Benchmark Consortium, 2012

    2012

  13. [20]

    Gemini: A family of highly capable multimodal models, 2024

    Gemini Team. Gemini: A family of highly capable multimodal models, 2024

    2024

  14. [21]

    Zifan Carl Guo and William S. Moses. Enabling transformers to understand low-level programs. In2022 IEEE High Performance Extreme Computing Conference (HPEC), pages 1–9, 2022

    2022

  15. [22]

    Hint: A new way to measure computer performance

    John L Gustafson and Quinn O Snell. Hint: A new way to measure computer performance. In Proceedings of the Twenty-Eighth Annual Hawaii International Conference on System Sciences, volume 2, pages 392–401. IEEE, 1995

    1995

  16. [23]

    Same task, more tokens: the impact of input length on the reasoning performance of large language models

    Mosh Levy, Alon Jacoby, and Yoav Goldberg. Same task, more tokens: the impact of input length on the reasoning performance of large language models. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar, editors,Proceedings of the 62nd Annual Meeting of the Association for Computat...

    2024

  17. [24]

    Retrieval augmented generation or long-context llms? a comprehensive study and hybrid approach, 2024

    Zhuowan Li, Cheng Li, Mingyang Zhang, Qiaozhu Mei, and Michael Bendersky. Retrieval augmented generation or long-context llms? a comprehensive study and hybrid approach, 2024

    2024

  18. [25]

    J. Liu, F. Zhang, X. Zhang, Z. Yu, L. Wang, Y . Zhang, and B. Guo. hmcodetrans: Hu- man–machine interactive code translation.IEEE Transactions on Software Engineering, 50(05):1163–1181, may 2024

    2024

  19. [26]

    Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang

    Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. Lost in the middle: How language models use long contexts.Transactions of the Association for Computational Linguistics, 12:157–173, 2024

    2024

  20. [27]

    Clangd: C/c++ language server

    LLVM Project. Clangd: C/c++ language server. https://clangd.llvm.org/, 2024. Ac- cessed: 2024-09-14. 11

    2024

  21. [28]

    LLVM Foundation, 2024

    LLVM Project.The LLVM Compiler Infrastructure. LLVM Foundation, 2024. Version 18.1.8

    2024

  22. [29]

    Codexglue: A machine learning benchmark dataset for code understanding and generation.arXiv preprint arXiv:2102.04664, 2021

    Shuai Lu, Daya Guo, Shuo Ren, Junjie Huang, Alexey Svyatkovskiy, Ambrosio Blanco, Colin Clement, Dawn Drain, Daxin Jiang, Duyu Tang, et al. Codexglue: A machine learning benchmark dataset for code understanding and generation.arXiv preprint arXiv:2102.04664, 2021

    2021 arXiv

  23. [30]

    Intellisense in visual studio code

    Microsoft Corporation. Intellisense in visual studio code. https://code.visualstudio. com/docs/editor/intellisense, 2024. Accessed: 2024-09-14

    2024

  24. [31]

    Sewon Min, Xinxi Lyu, Ari Holtzman, Mikel Artetxe, Mike Lewis, Hannaneh Hajishirzi, and Luke Zettlemoyer. Rethinking the role of demonstrations: What makes in-context learning work? In Yoav Goldberg, Zornitsa Kozareva, and Yue Zhang, editors,Proceedings of the 2022 Conference ...

    2022

  25. [32]

    Llm4vv: Developing llm- driven testsuite for compiler validation.Future Generation Computer Systems, 2024

    Christian Munley, Aaron Jarmusch, and Sunita Chandrasekaran. Llm4vv: Developing llm- driven testsuite for compiler validation.Future Generation Computer Systems, 2024

    2024

  26. [33]

    Ansibench: A selection of ansi c benchmarks and programs useful as benchmarks, 2024

    nfinit. Ansibench: A selection of ansi c benchmarks and programs useful as benchmarks, 2024. Accessed: 2024-11-22

    2024

  27. [34]

    Anh Tuan Nguyen, Tung Thanh Nguyen, and Tien N. Nguyen. Divide-and-conquer approach for multi-phase statistical migration for source code. InProceedings of the 30th IEEE/ACM International Conference on Automated Software Engineering, ASE ’15, page 585–596. IEEE Press, 2015

    2015

  28. [35]

    Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar- Lezama

    Theo X. Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando Solar- Lezama. Is self-repair a silver bullet for code generation? InThe Twelfth International Conference on Learning Representations, 2024

    2024

  29. [36]

    Gpt-4 technical report, 2023

    OpenAI, :, Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Flo- rencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, Red Avila, Igor Babuschkin, Suchir Balaji, Valerie Balcom, Paul Baltescu, Haiming Bao, Mo Bavarian, Jeff B...

    2023

  30. [37]

    Chatgpt: Optimizing language models for dialogue.OpenAI, 2023

    OpenAI. Chatgpt: Optimizing language models for dialogue.OpenAI, 2023

    2023

  31. [38]

    Gpt-4o system card

    OpenAI. Gpt-4o system card. https://openai.com/index/gpt-4o-system-card/ , Au- gust 2024. Accessed on September 15, 2024

    2024

  32. [39]

    Video generation models as world simulators

    OpenAI. Video generation models as world simulators. https://openai.com/index/ video-generation-models-as-world-simulators/, 2024. Technical Report

    2024

  33. [40]

    Introducing GPT-4.1 in the API

    OpenAI. Introducing GPT-4.1 in the API. https://openai.com/index/gpt-4-1/ , April

  34. [41]

    Liangming Pan, Michael Saxon, Wenda Xu, Deepak Nathani, Xinyi Wang, and William Yang Wang. Automatically correcting large language models: Surveying the landscape of diverse automated correction strategies.Transactions of the Association for Computational Linguistics, 12:484–506, 2024

    2024

  35. [42]

    High- resolution image synthesis with latent diffusion models

    Robin Rombach, Andreas Blattmann, Dominik Lorenz, Patrick Esser, and Björn Ommer. High- resolution image synthesis with latent diffusion models. InProceedings of the IEEE/CVF conference on computer vision and pattern recognition, pages 10684–10695, 2022

    2022

  36. [43]

    Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950, 2022

    Baptiste Rozière, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiaoqing Ellen Tan, Yossi Adi, Jingyu Liu, Tal Remez, Jérémy Rapin, et al. Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950, 2022

    2022 arXiv

  37. [44]

    Unsuper- vised translation of programming languages

    Baptiste Rozière, Marie-Anne Lachaux, Lowik Chanussot, and Guillaume Lample. Unsuper- vised translation of programming languages. In Hugo Larochelle, Marc’Aurelio Ranzato, Raia Hadsell, Maria-Florina Balcan, and Hsuan-Tien Lin, editors,Advances in Neural Information Processing...

    2020

  38. [45]

    Leveraging automated unit tests for unsupervised code translation.arXiv preprint arXiv:2110.06773, 2021

    Baptiste Roziere, Jie M Zhang, Francois Charton, Mark Harman, Gabriel Synnaeve, and Guillaume Lample. Leveraging automated unit tests for unsupervised code translation.arXiv preprint arXiv:2110.06773, 2021

    2021 arXiv

  39. [46]

    Can many-shot in-context learning help long- context llm judges? see more, judge better!, 2024

    Mingyang Song, Mao Zheng, and Xuan Luo. Can many-shot in-context learning help long- context llm judges? see more, judge better!, 2024

    2024

  40. [47]

    System v application binary interface: Amd64 architecture processor supplement (with lp64 and ilp32 programming models) version 1.0

    System V ABI. System v application binary interface: Amd64 architecture processor supplement (with lp64 and ilp32 programming models) version 1.0. Technical report, The Santa Cruz Operation, Inc., 2018

    2018

  41. [48]

    Code translation with compiler representations

    Marc Szafraniec, Baptiste Rozière, Hugh Leather, Patrick Labatut, François Charton, and Gabriel Synnaeve. Code translation with compiler representations. InThe Eleventh Interna- tional Conference on Learning Representations, ICLR 2023, Kigali, Rwanda, May 1-5, 2023. OpenReview...

    2023

  42. [49]

    Progressive gener- ation of long text with pretrained language models

    Bowen Tan, Zichao Yang, Maruan Al-Shedivat, Eric Xing, and Zhiting Hu. Progressive gener- ation of long text with pretrained language models. In Kristina Toutanova, Anna Rumshisky, Luke Zettlemoyer, Dilek Hakkani-Tur, Iz Beltagy, Steven Bethard, Ryan Cotterell, Tanmoy Chakrabo...

    2021

  43. [50]

    Iteratively prompt pre-trained language models for chain of thought

    Boshi Wang, Xiang Deng, and Huan Sun. Iteratively prompt pre-trained language models for chain of thought. In Yoav Goldberg, Zornitsa Kozareva, and Yue Zhang, editors,Proceedings of the 2022 Conference on Empirical Methods in Natural Language Processing, pages 2714–2730, Abu D...

    2022

  44. [51]

    Planning in natural language improves llm search for code generation, 2024

    Evan Wang, Federico Cassano, Catherine Wu, Yunfeng Bai, Will Song, Vaskar Nath, Ziwen Han, Sean Hendryx, Summer Yue, and Hugh Zhang. Planning in natural language improves llm search for code generation, 2024

    2024

  45. [52]

    LEGO-prover: Neural theorem proving with growing libraries

    Haiming Wang, Huajian Xin, Chuanyang Zheng, Zhengying Liu, Qingxing Cao, Yinya Huang, Jing Xiong, Han Shi, Enze Xie, Jian Yin, Zhenguo Li, and Xiaodan Liang. LEGO-prover: Neural theorem proving with growing libraries. InThe Twelfth International Conference on Learning Represen...

    2024

  46. [53]

    Compilable neural code generation with compiler feedback

    Xin Wang, Yasheng Wang, Yao Wan, Fei Mi, Yitong Li, Pingyi Zhou, Jin Liu, Hao Wu, Xin Jiang, and Qun Liu. Compilable neural code generation with compiler feedback. In Smaranda Muresan, Preslav Nakov, and Aline Villavicencio, editors,Findings of the Association for Computationa...

    2022

  47. [54]

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven C. H. Hoi. Codet5: Identifier-aware unified pre-trained encoder-decoder models for code understanding and generation, 2021

    2021

  48. [55]

    Chain-of-thought prompting elicits reasoning in large language models

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, brian ichter, Fei Xia, Ed Chi, Quoc V Le, and Denny Zhou. Chain-of-thought prompting elicits reasoning in large language models. In S. Koyejo, S. Mohamed, A. Agarwal, D. Belgrave, K. Cho, and A. Oh, editors, Advances in N...

    2022

  49. [56]

    Babeltower: Learning to auto-parallelized program translation

    Yuanbo Wen, Qi Guo, Qiang Fu, Xiaqing Li, Jianxing Xu, Yanlin Tang, Yongwei Zhao, Xing Hu, Zidong Du, Ling Li, et al. Babeltower: Learning to auto-parallelized program translation. InInternational Conference on Machine Learning, pages 23685–23700. PMLR, 2022

    2022

  50. [57]

    Addison-Wesley Reading, 1996

    Niklaus Wirth, Niklaus Wirth, Niklaus Wirth, Suisse Informaticien, and Niklaus Wirth.Compiler construction, volume 1. Addison-Wesley Reading, 1996

    1996

  51. [58]

    Data augmentation for code translation with comparable corpora and multiple references

    Yiqing Xie, Atharva Naik, Daniel Fried, and Carolyn Rose. Data augmentation for code translation with comparable corpora and multiple references. In Houda Bouamor, Juan Pino, and Kalika Bali, editors,Findings of the Association for Computational Linguistics: EMNLP 2023, pages ...

    2023

  52. [59]

    Finding and understanding bugs in c compilers

    Xuejun Yang, Yang Chen, Eric Eide, and John Regehr. Finding and understanding bugs in c compilers. InProceedings of the 32nd ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI ’11, page 283–294, New York, NY , USA, 2011. Association for Computing Machinery

    2011

  53. [60]

    Exploring and unleashing the power of large language models in automated code translation.Proc

    Zhen Yang, Fang Liu, Zhongxing Yu, Jacky Wai Keung, Jia Li, Shuo Liu, Yifan Hong, Xiaoxue Ma, Zhi Jin, and Ge Li. Exploring and unleashing the power of large language models in automated code translation.Proc. ACM Softw. Eng., 1(FSE), jul 2024

    2024

  54. [61]

    Large language models meet NL2Code: A survey

    Daoguang Zan, Bei Chen, Fengji Zhang, Dianjie Lu, Bingchao Wu, Bei Guan, Wang Yongji, and Jian-Guang Lou. Large language models meet NL2Code: A survey. In Anna Rogers, Jordan Boyd-Graber, and Naoaki Okazaki, editors,Proceedings of the 61st Annual Meeting of the Association for...

    2023

  55. [62]

    Parsel: Al- gorithmic reasoning with language models by composing decompositions

    Eric Zelikman, Qian Huang, Gabriel Poesia, Noah Goodman, and Nick Haber. Parsel: Al- gorithmic reasoning with language models by composing decompositions. InThirty-seventh Conference on Neural Information Processing Systems, 2023

    2023

  56. [64]

    Alice Li, Andrew Rice, Devon Rifkin, Shawn Simis- ter, Ganesh Sittampalam, and Edward Aftandilian

    Albert Ziegler, Eirini Kalliamvakou, X. Alice Li, Andrew Rice, Devon Rifkin, Shawn Simis- ter, Ganesh Sittampalam, and Edward Aftandilian. Measuring github copilot’s impact on productivity.Commun. ACM, 67(3):54–63, February 2024. 15 A Composability of C-like Language Construct...

    2024

  57. [66]

    Control Flow: The order of execution is preserved (stmt_1 then stmt_2). 2. Data Flow: The value of ’a’ computed in stmt_1 is correctly used in stmt_2. 3. Independence: The translation of stmt_2 does not depend on how stmt_1 was translated, only on its effect (the value of ’a’)...

  58. [67]

    Translation structure: 17 T(basic_for_loop): T(B_init) loop_start: T(B_cond) jz loop_end T(B_body) T(B_incr) jmp loop_start loop_end:

    For Loop: LetB init,B cond,B incr, andB body be the basic blocks for init, cond, incr, and body respectively. Translation structure: 17 T(basic_for_loop): T(B_init) loop_start: T(B_cond) jz loop_end T(B_body) T(B_incr) jmp loop_start loop_end:

  59. [68]

    Control Flow Preservation: The structure of jump instructions preserves the original control flow. 2. Data Flow Preservation: The order of operations within and between blocks is maintained

  60. [69]

    Therefore, the basic for loop is composable under T

    Composability: T(basic_f or_loop)≡T(B init)·T(B cond)·T(B body)·T(B incr), where · represents concatenation with appropriate jump instructions. Therefore, the basic for loop is composable under T . Similar proofs can be constructed for other basic control structures

  61. [70]

    If-Else Statement: Let Bcond, Bthen, and Belse be the basic blocks for condition, then-branch, and else-branch respectively. Translation structure: T(basic_if_else): T(B_cond) jz else_label T(B_then) jmp end_label else_label: T(B_else) end_label: Control flow and data flow pre...

  62. [71]

    Translation structure: T(basic_while): loop_start: T(B_cond) jz loop_end T(B_body) jmp loop_start loop_end:

    While Loop: LetB cond andB body be the basic blocks for condition and body respectively. Translation structure: T(basic_while): loop_start: T(B_cond) jz loop_end T(B_body) jmp loop_start loop_end:

  63. [72]

    Translation structure: T(basic_do_while): loop_start: T(B_body) T(B_cond) jnz loop_start

    Do-While Loop: LetB body andB cond be the basic blocks for body and condition respectively. Translation structure: T(basic_do_while): loop_start: T(B_body) T(B_cond) jnz loop_start

  64. [73]

    Translation structure: T(basic_switch): T(B_expr) 18 cmp result, case1_value je case1_label cmp result, case2_value je case2_label

    Switch-Case Statement: Let Bexpr be the basic block for the switch expression, andB1, B2, ..., Bn be the basic blocks for each case. Translation structure: T(basic_switch): T(B_expr) 18 cmp result, case1_value je case1_label cmp result, case2_value je case2_label ... jmp defau...

  65. [74]

    Break Statement: Translation structure: T(break): jmp loop_end_label_depth Whereloop_end_label_depthcorresponds to the end of the current loop at depthloop_depth

  66. [75]

    Control flow is preserved by jumping to the appropriate label based on the current loop depth

    Continue Statement: Translation structure: T(continue): jmp loop_continue_label_depth Where loop_continue_label_depth corresponds to the continuation point of the current loop at depthloop_depth. Control flow is preserved by jumping to the appropriate label based on the curren...

  67. [76]

    The algorithm starts with basic blocks and basic control structures, which are proven composable by Theorem 1 and Theorem 2

  68. [77]

    • Control structures with all composable subparts are marked composable

    It iteratively builds up composability for larger structures: • Sequences of composable blocks are proved composable by Theorem 4. • Control structures with all composable subparts are marked composable

  69. [78]

    The process continues until the entire program is marked composable or no further progress can be made

  70. [79]

    Therefore, if the algorithm returns that P is composable, then P is indeed composable under the translation functionT

    If the entire program is marked composable, it means that T(P) can be expressed as a composition of the translations of its composable parts, preserving both control flow and data flow as per Definition 8. Therefore, if the algorithm returns that P is composable, then P is ind...

  71. [80]

    The core of our argument relies on the decomposition of programs into control blocks and the composability of these blocks

    Simplification and Correctness:The simplifications made in our language model and translation process do not compromise the validity of the proof. The core of our argument relies on the decomposition of programs into control blocks and the composability of these blocks. The in...

  72. [81]

    This assumption is crucial for maintaining the direct correspondence between source code structures and their translations

    Unoptimized Translation:Our proof assumes a straightforward, unoptimized translation process. This assumption is crucial for maintaining the direct correspondence between source code structures and their translations

  73. [82]

    For example: • Exception Handling: Languages with sophisticated exception handling mechanisms, such as Python, introduce complexities that can break composability

    Limitations for Complex Language Features:The composability principle as proved here can be applied to C-like languages, but may not hold for more complex language features. For example: • Exception Handling: Languages with sophisticated exception handling mechanisms, such as ...

  74. [83]

    However, many real-world compiler opti- mizations operate across these boundaries

    Optimizations Across Basic Blocks:Our proof assumes that the boundaries of control blocks are respected in the translation process. However, many real-world compiler opti- mizations operate across these boundaries. Examples include: • Loop unrolling • Function inlining • Globa...

  75. [84]

    numerical

    Applicability:Despite these limitations, the composability principle proved here is valuable for: • The foundation of LEGO translation method, the proof reveals the composable nature of code in at least control block level, which is a major difference than natural languages. •...

    1922

  76. [2025]

    Accessed: 2025-05-04

    2025

Pith tools

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