Pith. sign in

REVIEW 4 major objections 5 minor 34 references

GroupTuner: Efficient Group-Aware Compiler Auto-Tuning

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

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

Pith's one-line read Grouping compiler flags by the optimization passes that use them, then mutating one group at a time, finds better GCC option combinations in less time than methods that first try to infer which individual options matter.

desk verdict GroupTuner is a solid empirical compiler tuning paper whose group-aware mechanism is plausible but not yet isolated from seeding and annealing choices; it deserves a referee who asks for an ablation. read the letter →

arxiv 2505.08598 v2 pith:RGNQGZWQ submitted 2025-05-13 cs.SE

Bingyu Gao , Mengyu Yao , Ziming Wang , Dong Liu , Ding Li , Xiangqun Chen , Yao Guo This is my paper · ORCID
classification cs.SE
keywords compilerauto-tuningGCCoptimizationoptionsoptiongroupingpass-basedgroupmutationsimulatedannealingiterativeperformancetuning
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

The paper claims that when tuning GCC's optimization options for a particular program, it is more effective to mutate coherent groups of flags than to first identify which individual flags are critical. It proposes GroupTuner, which statically groups 206 GCC options into 15 clusters according to the compiler passes that gate or execute them, and then repeatedly mutates one randomly chosen group within the best option combinations found so far, guided by a simulated-annealing acceptance rule. Across 36 benchmark programs, the paper reports the best-performing combination in 75% of cases and an average gain of 12.39% over -O3, surpassing the strongest existing method by 1.83 percentage points while taking roughly 2.5x less tuning time. If this holds, compiler auto-tuning can be built on pass-structure priors rather than fragile importance inference in a sparse, noisy, high-dimensional search space.

What carries the argument

The load-bearing mechanism is the pair of a static option grouping and a history-guided group-mutation search. The grouping is built once per compiler version by static analysis of GCC's source: locate each option's use sites, associate options with the pass that gates or executes them, merge groups sharing options, and assign leftovers to the nearest group according to the pass order in gcc/passes.def, producing 15 groups of 4-28 options. The search initializes from -O3 and the candidate list of the ten best configurations; each iteration selects a candidate at random, picks a group at random, flips each option in that group with probability 1/2, and keeps worse results with probability $e^{-\Delta/(T\alpha)}$ under a cooling temperature. This combination keeps adjustments locally coherent: the unchanged groups preserve the base configuration's validated behavior, while the mutated group can be explored for internal synergies without perturbing the rest of the vector.

What would settle it

Run GroupTuner on the same 36 benchmarks with 15 equally sized groups formed by random permutation of the 206 flags instead of pass-coherence grouping, keeping every other setting fixed; if the random-group version matches or beats the pass-group version, the proposed grouping mechanism is not the source of the reported advantage. Also check a program from the paper's case study (telecom_gsm) where -ftree-loop-if-convert hurts when combined with -ftree-loop-vectorize; GroupTuner should still find the configuration that enables only the vectorizer, since both flags sit in the same Loop-1 group.

Watch

Extended reading notes

Core claim

GroupTuner's central claim is that explicit critical-option identification is not a necessary step in compiler auto-tuning. The method maps every GCC optimization flag to the optimization pass or passes that read it (using static analysis of GCC internals), merges overlapping option-pass clusters, and assigns ungrouped flags to nearby groups by pipeline order, yielding 15 functionally coherent groups. The search then keeps a list of the ten best full option configurations observed, randomly picks one as a base, mutates only the flags inside a single randomly chosen group, and retains the result either because it improves the list or probabilistically through simulated annealing. The paper argues that this preserves the proven-good parts of earlier combinations while concentrating exploration where functional relatedness makes synergistic interactions likely, and reports that the resulting combinations outperform -O3 by an average of 12.39%, beat the strongest baseline (Bayesian optimization with random-forest importance inference) by 1.83 percentage points, and finish in only 39.25% of that baseline's average tuning time.

Load-bearing premise

The premise that flags used by the same pass or the same optimization stage are functionally related enough that mutating one such group at a time preserves gains and discovers synergies; the paper does not compare this pass-based grouping against random or data-driven groupings of the same size.

Editorial extensions

If this is right

  • Programs can be auto-tuned with more headroom: the reported 12.39% average gain over -O3 comes on top of a default that GCC itself chose, so the practical benefit is real speedup without manual flag expertise.
  • Tuning budgets become smaller: at 77.21% of random-search time and 39.25% of the strongest model-based baseline's time, per-program tuning becomes viable for programs with longer running times.
  • A single static grouping serves all programs on a given compiler version, so new programs do not trigger additional grouping cost during tuning.
  • Loop and GIMPLE-phase option groups carry the largest share of observed gains (averaging 5.05% and 2.83%), pointing users to where optimization effort pays off for GCC-like pipelines.

Reading between the lines

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

  • A direct way to test the paper's explanation is to rerun the same search with randomly permuted groups of identical sizes; if random groups perform just as well, group coherence is not what carries the gains, even if GroupTuner still wins.
  • The pass-based grouping is GCC-specific, but the same principle could be realized in pass-reorderable compilers by learning groups from program IR transformations or observed flag interactions across a corpus, a step the paper leaves to future work.
  • The efficiency gap is likely to widen as program runtimes grow, since GroupTuner's per-iteration overhead is near zero while model-based methods retrain each round, so the measured 2.5x advantage may understate the practical benefit on long-running workloads.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 proposes GroupTuner, a GCC compiler-option auto-tuner that statically partitions 206 optimization options into 15 groups derived from GCC pass structure, then performs a simulated-annealing-style search that mutates one group at a time, seeded from the -O3 configuration. Across 36 benchmarks from cBench, PolyBench, and SPEC CPU2017 with 500 tuning iterations, GroupTuner reports the best improvement over -O3 on 27/36 programs, an average improvement of 12.39%, compared with 10.56% for BOCA, while using 77.21% of RIO's wall-clock time. Additional experiments report 1000-iteration behavior and results on GCC 11.5.0 and 13.1.0.

Significance. If the mechanism claim holds, GroupTuner is a useful contribution: it replaces expensive per-iteration model training with a cheap, compiler-structure-derived search prior, and its cross-version and long-run experiments suggest robustness beyond a single compiler snapshot. The paper has notable strengths: an available artifact, careful measurement noise control (Turbo Boost off, core pinning, five-run averages, output-correctness checks), comparisons against five methods using their own code, and a clean separation of the grouping construction from benchmark outcomes, so the approach is not circularly fitted to the evaluation set. The main weakness is that the causal role of the pass-derived grouping is not isolated, and the headline numerical margins lack repeated-run statistics.

major comments (4)
  1. [§4.2, §5.6] The central claim is that functionally coherent, pass-derived groups are what make GroupTuner successful. The evaluation never compares the 15 pass-derived groups against alternative partitions, such as random partitions of the same 206 options into 15 groups of matched size, different group counts, or data-driven clusters. The RQ4 analysis in Figure 9 only shows that mutating some groups is associated with larger improvements during the actual search; it does not show that the pass-derived grouping outperforms other partitions. Without such a control, the observed advantage over global SA could be due to any constrained local-mutation scheme.
  2. [§5.2, Algorithm 1] Algorithm 1 depends on T0, Tmin, coolr, alpha, round_init, and the candidate-list size, and Section 5.2 states that the SA baseline is 'configured similarly' but mutates globally. None of these values is reported anywhere in the paper. If the two methods use different annealing schedules or different initialization rounds, the comparison is confounded. Please report the exact hyperparameters and include a sensitivity analysis, or compare GroupTuner with a global-mutation variant that uses the identical schedule.
  3. [Table 3] Table 3 reports a single best-observed percentage per program for each algorithm. All compared methods are stochastic in candidate selection and mutation, so a single run per program cannot establish the 1.83-percentage-point average margin over BOCA, nor can it support the claim that GroupTuner is best on 75% of programs. I request multiple seeds with confidence intervals, or at least a paired statistical test over programs for the average improvement, for the main 500-iteration results and for Tables 4 and 5.
  4. [§5.4, Figure 5] The comparison is partly confounded by initialization: Section 5.4 notes that GroupTuner starts from -O3, while BOCA, SRTuner, and CFSCA begin from randomly generated combinations. The early and possibly final advantages of GroupTuner are therefore inherited in part from the expert-designed -O3 starting point rather than from the group-aware mutation mechanism. The paper should add a randomly initialized GroupTuner variant, or re-run all baselines from the same -O3 seed, to isolate the contribution of the grouping and history-guided search.
minor comments (5)
  1. [§5.1, §5.2] Section 5.1 says the number of iterations is set to 500, while Section 5.2 says the three state-of-the-art methods are run with 'the source code and the default settings they provide.' Please clarify whether the default iteration counts of BOCA, CFSCA, and SRTuner were overridden to 500.
  2. [§6.2, Table 4] Table 4 reports 1000-iteration values but does not give the corresponding 500-iteration values for the same subset of programs, so the claim that GroupTuner 'continues to discover improved optimization combinations beyond 500 iterations' cannot be directly verified from the table; please include both columns.
  3. [§5.6, Figure 9] The metric in Figure 9, 'average performance contribution' of each group, is underspecified: it should be stated exactly how per-iteration improvements are attributed to a group, given that the base combination varies across iterations.
  4. [§2, Listing 1] There are duplicated and mis-referenced labels in the text: 'Listing 1' appears twice for different listings, and Figure 10 is referenced before the listing it refers to. Please renumber the listings and figures consistently.
  5. [Throughout] The terms 'round' and 'iteration' are used interchangeably; please unify them, and define in Algorithm 1 that 'perf' denotes execution time so that lower values are better.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: GroupTuner's grouping comes from GCC source structure, results are empirical external measurements, and no fitted parameter is renamed as a prediction.

full rationale

The paper's derivation chain is self-contained in the relevant sense. The grouping mechanism is constructed from static analysis of GCC internals, not from benchmark outcomes: 'We use CodeQL to perform static analysis of the GCC source code... Through this process, we categorize 206 options into 15 functionally coherent groups' (Section 4.2). The claimed 12.39% average improvement and the 1.83% edge over BOCA are direct measurements of execution time on cBench, PolyBench, and SPEC CPU2017 against a -O3 baseline, not quantities fitted by the method. The search uses historically best-performing combinations as mutation bases, but that is the algorithm's own mechanism rather than a circular reuse of its output as input. RQ4's group-contribution analysis is explicitly post hoc: it computes average gains 'brought by mutating each option group in every iteration across all benchmarks' and is not used to construct or fit the tuner. No self-citation is load-bearing: the framework extends the external SRTuner system and every comparison baseline is an external implementation with its own source code. The missing grouping ablation (e.g., random groups) weakens causal attribution of the gain to the pass-derived partition, and the paper itself concedes limitations in Section 6.1 (fixed mutation policy, GCC-specific scalability), but absence of an ablation is a correctness/evidence concern, not circularity. No equation reduces to its inputs and no fitted parameter is presented as a prediction, so a non-finding is the honest outcome.

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

The central claim rests on the static grouping premise and on a simulated-annealing schedule whose constants are undisclosed. The free parameters are the SA schedule and list size; they are not reported as fitted to data, but their sensitivity is unexplored. No new entities are postulated; the option groups are derived from GCC internals rather than invented.

free parameters (7)
  • T0 (initial SA temperature)
    Controls initial acceptance of worse combinations in the simulated-annealing criterion (Eq. 1); value not reported in the paper.
  • Tmin (termination temperature)
    Threshold that ends the iterative search; value not reported.
  • coolr (cooling rate)
    Multiplicative temperature decay per iteration (T = T * coolr); value not reported.
  • alpha (scaling factor)
    Scales temperature in the acceptance probability exp(-Delta/(T*alpha)); value not reported.
  • round_init (initialization rounds)
    Number of random group-mutated seeds generated from -O3 before the iterative phase; value not reported.
  • candidate list size = 10
    The number of top-performing combinations retained in comblist; stated in Sec 5.1.
  • per-option mutation probability = 0.5
    Each option in the selected group is reversed with probability 0.5 (Algorithm 1, line 5).
assumptions (5)
  • domain assumption GCC pass structure is a reliable proxy for functional option interactions
    Sec 4.2 states that options invoked by the same pass or same stage have a higher probability of synergistic effects; this is the basis for the 15 static groups and is not independently validated against alternative groupings.
  • domain assumption Mean execution time over 5 runs on a pinned core with Turbo Boost disabled is a stable estimator of performance
    Sec 5.1 Measurement; all performance comparisons, including the headline 12.39%, rely on this estimator.
  • domain assumption The 36 selected benchmark programs are representative of tuning workloads
    Sec 5.1 Datasets; the set excludes programs with <1% tuning gain, nondeterministic output, and most SPEC CPU2017 cases.
  • standard math The simulated annealing schedule avoids premature convergence in this discrete boolean-flag space
    The paper borrows standard SA (Bertsimas and Tsitsiklis) without a problem-specific convergence analysis.
  • domain assumption Per-iteration compile-and-execute time dominates algorithmic overhead, so wall-clock time is the right efficiency measure
    RQ3 compares total tuning time; this assumes measurement cost is the same across methods and that model-training overhead is the differentiator.

how reviews work

0 comments
Cite this review

Pith. "Pith review of GroupTuner: Efficient Group-Aware Compiler Auto-Tuning." pith.science (2026). https://pith.science/paper/RGNQGZWQ

@misc{pith2026250508598,
  author       = {Pith},
  title        = {Pith review of: GroupTuner: Efficient Group-Aware Compiler Auto-Tuning},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RGNQGZWQ}},
  note         = {Machine review of arXiv:2505.08598}
}
read the original abstract

Modern compilers typically provide hundreds of options to optimize program performance, but users often cannot fully leverage them due to the huge number of options. While standard optimization combinations (e.g., -O3) provide reasonable defaults, they often fail to deliver near-peak performance across diverse programs and architectures. To address this challenge, compiler auto-tuning techniques have emerged to automate the discovery of improved option combinations. Existing techniques typically focus on identifying critical options and prioritizing them during the search to improve efficiency. However, due to limited tuning iterations, the resulting data is often sparse and noisy, making it highly challenging to accurately identify critical options. As a result, these algorithms are prone to being trapped in local optima. To address this limitation, we propose GroupTuner, a group-aware auto-tuning technique that directly applies localized mutation to coherent option groups based on historically best-performing combinations, thus avoiding explicitly identifying critical options. By forgoing the need to know precisely which options are most important, GroupTuner maximizes the use of existing performance data, ensuring more targeted exploration. Extensive experiments demonstrate that GroupTuner can efficiently discover competitive option combinations, achieving an average performance improvement of 12.39% over -O3 while requiring only 77.21% of the time compared to the random search algorithm, significantly outperforming state-of-the-art methods.

Figures

Figures reproduced from arXiv: 2505.08598 by the authors.

Figure 2
Figure 2. Iterative tuning process of telecom_adpcm_c in CFSCA and SRTuner. As shown in the left subfigure of [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Overview of GroupTuner. Compilers organize the optimization process into mul￾tiple stages, each consisting of several passes executed se￾quentially. Passes within the same optimization stage usu￾ally share similar or closely related optimization goals. Con￾sequently, options invoked by the same pass or by passes within the same stage have a higher probability of exhibiting synergistic effects. Thus, we group options… view at source ↗
Figure 4
Figure 4. Performance average improve￾ments every 50 rounds. 0 100 200 300 400 500 Iteration Round −0.15 −0.10 −0.05 0.00 0.05 0.10 Average Performance Improvement over O3 GroupTuner BOCA SRTuner CFSCA [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
Figures from the paper (3 more)
Figure 9
Figure 9. Figure 9: Top-5 groups with the highest average perfor￾mance contribution. better regions of the search space. Even when suboptimal combinations occasionally emerge, they are probabilistically discarded early, thus avoiding prolonged execution times and unnecessary resource cons…
Figure 7
Figure 7. Figure 7: Performance trends of option combinations found by GroupTuner and BOCA. 0.00 0.01 0.02 0.03 0.04 0.05 automotive_qsort1 0.000 0.005 0.010 0.015 0.020 0.025 0.030 0.035 bzip2d 0 100 200 300 400 500 0.00 0.02 0.04 0.06 0.08 0.10 network_dijkstra 0 100 200 300 400 500 0.0…
Figure 8
Figure 8. Figure 8: Best observed performance improvement during tuning process. based on previously identified better combinations. It en￾sures newly generated combinations largely remain within 5.05 2.83 2.43 1.85 1.83 0 1 2 3 4 5 LOOP 1 GIMPLE 2 INLINE LOOP 2 BRANCH Average Perf Contri…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

34 extracted references · 24 canonical work pages

  1. [1]

    cBench.https://sourceforge.net/projects/cbenchmark/files/ cBench/V1.1/

    2024. cBench.https://sourceforge.net/projects/cbenchmark/files/ cBench/V1.1/. Accessed: 2024.3.1

    work page 2024

  2. [2]

    Optimize Options - Using the GNU Compiler Collection (GCC)

    2024. Optimize Options - Using the GNU Compiler Collection (GCC). https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html. Accessed: [2024.3.1]

    work page 2024

  3. [3]

    Perf.https://perf.wiki.kernel.org/index.php/Main_Page

    2024. Perf.https://perf.wiki.kernel.org/index.php/Main_Page. Ac- cessed: [2024.3.1]

    work page 2024

  4. [4]

    PolyBench.https://web.cs.ucla.edu/~pouchet/software/ polybench/

    2024. PolyBench.https://web.cs.ucla.edu/~pouchet/software/ polybench/. Accessed: 2024.3.1

    work page 2024

  5. [5]

    A. H. Ashouri, W. Killian, J. Cavazos, G. Palermo, and C. Silvano. 2018. A survey on compiler autotuning using machine learning.ACM Com- puting Surveys (CSUR)51, 5 (2018), 1–42

    work page 2018

  6. [6]

    Dimitris Bertsimas and John Tsitsiklis. 1993. Simulated annealing. Statist. Sci.8, 1 (1993), 10–15

    work page 1993

  7. [7]

    Kistowski

    James Bucek, Klaus-Dieter Lange, and Jóakim v. Kistowski. 2018. SPEC CPU2017: Next-generation compute benchmark. InCompanion of the 2018 ACM/SPEC International Conference on Performance Engineering. 41–42

    2018

  8. [8]

    Junjie Chen, Ningxin Xu, Peiqi Chen, and Hongyu Zhang. 2021. Efficient Compiler Autotuning via Bayesian Optimization. In2021 IEEE/ACM 43rd International Conference on Software Engineering. IEEE, 1198–1209

    work page 2021

Show all 34 references
  1. [9]

    Yang Chen, Shuangde Fang, Yuanjie Huang, Lieven Eeckhout, Grigori Fursin, Olivier Temam, and Chengyong Wu. 2012. Deconstructing iterative optimization.ACM Transactions on Architecture and Code Optimization (TACO)9, 3 (2012), 1–30

    2012

  2. [10]

    Chris Cummins, Pavlos Petoumenos, Zheng Wang, and Hugh Leather

  3. [11]

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

    2023 arXiv

  4. [12]

    Chris Cummins, Volker Seeker, Dejan Grubisic, Baptiste Roziere, Jonas Gehring, Gabriel Synnaeve, and Hugh Leather. 2024. Meta Large Lan- guage Model Compiler: Foundation Models of Compiler Optimization. arXiv preprint arXiv:2407.02524(2024)

    2024 arXiv

  5. [13]

    Chris Cummins, Bram Wasti, Jiadong Guo, Brandon Cui, Jason Ansel, Sahir Gomez, Somya Jain, Jia Liu, Olivier Teytaud, Benoit Steiner, et al

  6. [14]

    Oege De Moor, Mathieu Verbaere, Elnar Hajiyev, Pavel Avgustinov, Torbjorn Ekman, Neil Ongkingco, Damien Sereni, and Julian Tibble

  7. [15]

    Fursin, C

    G. Fursin, C. Miranda, and O. Temam. 2008. MILEPOST GCC: machine learning based research compiler. GCC Summit

    2008

  8. [16]

    GG Fursin, Michael FP O’Boyle, and Peter MW Knijnenburg. 2005. Evaluating iterative compilation. InLanguages and Compilers for Par- allel Computing: 15th Workshop, LCPC 2002, College Park, MD, USA, July 25-27, 2002. Revised Papers 15. Springer, 362–376

    2005

  9. [17]

    Bingyu Gao, Mengyu Yao, Ziming Wang, Dong Liu, Ding Li, Xiangqun Chen, and Yao Guo. 2025. GroupTuner: Artifact for LCTES 2025. doi:10.5281/zenodo.15348539Artifact available at Zenodo

    2025 doi

  10. [18]

    Aurélien Garivier and Eric Moulines. 2011. On upper-confidence bound policies for switching bandit problems. InInternational conference on algorithmic learning theory. Springer, 174–188

    2011

  11. [19]

    Dejan Grubisic, Chris Cummins, Volker Seeker, and Hugh Leather

  12. [20]

    Hoste and L

    K. Hoste and L. Eeckhout. 2008. Cole: Compiler optimization level exploration. InProceedings of the 6th Annual IEEE/ACM International Symposium on Code Generation and Optimization. 165–174

    2008

  13. [21]

    Scott Kirkpatrick, C Daniel Gelatt Jr, and Mario P Vecchi. 1983. Opti- mization by simulated annealing.science220, 4598 (1983), 671–680

    1983

  14. [22]

    Volodymyr Kuleshov and Doina Precup. 2014. Algorithms for multi- armed bandit problems.arXiv preprint arXiv:1402.6028(2014)

    2014 arXiv

  15. [23]

    Sunghyun Park, Salar Latifi, Yongjun Park, Armand Behroozi, Byung- soo Jeon, and Scott Mahlke. 2022. SRTuner: Effective compiler op- timization customization by exposing synergistic relations. In2022 IEEE/ACM International Symposium on Code Generation and Optimiza- tion (CGO)....

    2022

  16. [24]

    Simranjit Singh, Andreas Karatzas, Michael Fore, Iraklis Anagnos- topoulos, and Dimitrios Stamoulis. 2024. An LLM-Tool Compiler for Fused Parallel Function Calling.arXiv preprint arXiv:2405.17438(2024)

    2024 arXiv

  17. [25]

    Jubi Taneja, Avery Laird, Cong Yan, Madan Musuvathi, and Shu- vendu K Lahiri. 2024. LLM-Vectorizer: LLM-based Verified Loop Vec- torizer.arXiv preprint arXiv:2406.04693(2024)

    2024 arXiv

  18. [26]

    Mircea Trofin, Yundi Qian, Eugene Brevdo, Zinan Lin, Krzysztof Choro- manski, and David Li. 2021. Mlgo: a machine learning guided compiler optimizations framework.arXiv preprint arXiv:2101.04808(2021)

    2021 arXiv

  19. [27]

    Paul Tseng. 2001. Convergence of a block coordinate descent method for nondifferentiable minimization.Journal of optimization theory and applications109 (2001), 475–494

    2001

  20. [28]

    Minjia Zhang, Menghao Li, Chi Wang, and Mingqin Li. 2020. Dy- naTune: Dynamic tensor program optimization in deep neural network compilation. InInternational Conference on Learning Representations

    2020

  21. [29]

    Mingxuan Zhu and Dan Hao. 2023. Compiler Auto-Tuning via Criti- cal Flag Selection. In2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 1000–1011

    2023

  22. [30]

    Mingxuan Zhu, Dan Hao, and Junjie Chen. 2024. Compiler Autotun- ing through Multiple Phase Learning.ACM Transactions on Software Engineering and Methodology(2024). Received 2025-03-21; accepted 2025-04-21

    2024

  23. [2007]

    ql for source code analysis

    Keynote address:. ql for source code analysis. InSeventh IEEE International Working Conference on Source Code Analysis and Manipu- lation (SCAM 2007). IEEE, 3–16

    2007

  24. [2017]

    In2017 26th International Conference on Parallel Architectures and Compilation Techniques (PACT)

    End-to-end deep learning of optimization heuristics. In2017 26th International Conference on Parallel Architectures and Compilation Techniques (PACT). IEEE, 219–232

  25. [2022]

    In2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO)

    Compilergym: Robust, performant compiler optimization envi- ronments for ai research. In2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 92–105

  26. [2024]

    Compiler generated feedback for Large Language Models.arXiv preprint arXiv:2403.14714(2024)

    2024 arXiv

Pith tools

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