Pith. sign in

REVIEW 3 major objections 5 minor 39 references

GRACE shows that a small cluster-specific coreset of pass sequences matches iterative compilation's code-size gains in under a second per program.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

T0 review · deepseek-v4-flash

2026-08-04 09:47 UTC pith:342MJXJE

load-bearing objection The code-size result is real; the abstract's execution-oriented claims are not supported by the body. the 3 major comments →

arxiv 2510.13176 v2 pith:342MJXJE submitted 2025-10-15 cs.SE

GRACE: Cluster-Specific Sequence Reuse for Compiler Auto-Tuning

classification cs.SE
keywords compiler auto-tuningphase orderingpass selectioncoresetcontrastive learninggenetic algorithmLLVMcode size optimization
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Compiler auto-tuning faces a trade-off: iterative compilation finds strong per-program optimization sequences but costs hundreds of seconds, while learned models are cheap but generalize poorly. GRACE's thesis is that a middle path exists: build a small 'coreset' of pass sequences offline, each specialized to a cluster of similar programs via evolutionary search, then at deployment just evaluate the handful of sequences and pick the best. The paper's key empirical claim is that on seven benchmark suites, this cluster-specific reuse beats LLVM's opt -Oz by about 10% in IR instruction count on two LLVM versions, with less than one second of tuning per program. If right, GRACE makes auto-tuning practical to deploy in ordinary compilation workflows without a runtime model.

Core claim

The central claim is that program similarity for optimization purposes can be captured by contrastive embeddings, and that grouping training programs by these embeddings and evolving one pass sequence per cluster yields a small, generic coreset that transfers to unseen programs. On its own terms, GRACE's discovery is that the cluster-specific coreset — built from synergy-seeded genetic search with mutation restricted to a curated pass pool — delivers roughly 10% instruction-count reduction over opt -Oz on both LLVM 10 and LLVM 18, with per-program deployment cost under one second.

What carries the argument

The core object is the cluster-specific coreset: a set of k pass sequences, one per program cluster, evolved by a genetic algorithm whose initial population is seeded from global synergy-based candidates and whose mutations draw only from a restricted pass pool. Programs are grouped by k-means on embeddings learned with a contrastive loss that treats compiler-transformed variants of the same program as positive pairs. At test time, the best of the k sequences is chosen by evaluation, with optional prefix-trimming and a fallback to opt -Oz.

Load-bearing premise

Programs that land in the same embedding cluster respond similarly to pass sequences, so that one evolved sequence per cluster stays near-optimal for each unseen program in that cluster.

What would settle it

Take a hold-out set of programs; for each, run a search with a generous budget (e.g., 200 seconds per program) to find its best pass sequence, then compare its instruction-count reduction to the reduction from the assigned cluster's coreset sequence. If the median gap is substantial (say >3 percentage points) or the coreset sequence is not within a small tolerance of the per-program optimum, the coreset generalization claim is not supported.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Compiler pipelines can ship a static coreset artifact instead of an online model, enabling auto-tuning in build systems with negligible overhead.
  • The approach transfers across LLVM versions with nearly identical gains, suggesting the method is not tied to a specific pass-set layout.
  • Because the contrastive embedding ablation changes end-to-end results (10.09% vs 9.25%), representation quality is a direct lever on auto-tuning success.
  • The opt -Oz fallback bounds downside risk, making the method safe for production compilation of unseen code.
  • The same coreset idea could extend to speed-oriented objectives, with estimated cycle-count gains of about 27% over opt -O3 reported.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • GRACE's homogeneity premise is only indirectly tested: internal metrics show cluster separation, but the paper never measures how far the core cluster's best sequence is from the per-program optimum on unseen programs; a testable extension is to report that gap.
  • If the embedding space truly aligns with optimization response, then the coreset could also serve as a warm start for iterative compilation, raising the ceiling when larger budgets are available.
  • The reported cycle-count reductions over opt -O3 are estimates, not end-to-end runtime for all suites; a natural next step is wall-clock speedup measurements on the full test set.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

3 major / 5 minor

Summary. The paper proposes GRACE, a compiler auto-tuning framework that constructs a small, cluster-specific coreset of optimization pass sequences. It combines global pass-synergy analysis and weighted scoring to generate initial candidate sequences and a pass pool, contrastive learning on Autophase features with pass-sequence-based augmentation to embed programs, k-means clustering of the resulting embeddings, and per-cluster genetic search to obtain k representative pass sequences. At deployment, GRACE evaluates the k sequences on the target program and optionally applies three lightweight refinements (prefix/derivative search, localized GA, opt -Oz fallback). The main reported empirical result is an average LLVM IR instruction-count reduction of 10.09% (LLVM 10.0.0) and 10.19% (LLVM 18.1.6) relative to opt -Oz, with less than one second per-program deployment time, based on seven benchmark suites.

Significance. If the code-size results hold, GRACE offers a practically meaningful balance: a static, human-readable coreset can deliver a large fraction of iterative compilation's benefit at low deployment cost, with a conservative fallback against regression below opt -Oz. The paper's strengths include evaluation on two LLVM versions, an embedding-quality comparison, an end-to-end embedding ablation, and a decomposition of the initialization/pass-pool contributions. However, the abstract's execution-oriented claims (cycle-count reductions and polybench speedups) are entirely unsupported by the body, and the central 'cluster-specific' premise is not directly isolated by a controlled global-coreset ablation. The manuscript also contains unresolved placeholders and inconsistent headline numbers, so it cannot currently be accepted as-is.

major comments (3)
  1. [Abstract; Sections 4-5] The abstract states that 'under an execution-oriented objective, GRACE reduces estimated cycle counts by 26.84% and 27.54% ... and also yields measurable end-to-end speedups on runnable cBench and polybench programs.' No such experiment appears in the body: Section 5 defines OverOz solely as LLVM IR instruction-count reduction (Eq. in §5.1), Table 1 lists no polybench programs, Table 2 and Figure 5 report only instruction-count OverOz, and Section 6 explicitly says the 'current instantiation of GRACE is designed for a single objective: reducing the LLVM IR instruction count.' These abstract claims are therefore unsupported and internally inconsistent. They should be removed or substantiated with an experimental section.
  2. [Abstract vs. Introduction/§5.2/§7] The headline code-size numbers are inconsistent across the paper. The abstract says 9.92%/10.30% average instruction-count reduction for LLVM 10.0.0/18.1.6, while the introduction, Section 5.2, and Section 7 say 10.09%/10.19%; Section 5.1 also refers to an average OverOz of 10.17% although Table 2 shows 10.09. Since these numbers are the paper's central quantitative claim, the authors must reconcile them and state exactly which experimental configuration yields each value.
  3. [§3.3, §5.3] The paper's core contribution is that cluster-specific coresets generalize better than a single global coreset. However, the evaluation never directly tests this premise. In Section 5.3, the ablation replaces the contrastive embeddings with PairVec, which changes the clustering but keeps the cluster-specific machinery intact; Table 2's comparison with Coreset-NVP is confounded by different search algorithms and budgets. There is no controlled comparison between GRACE with k=100 cluster-specific sequences and GRACE with a k=1 global coreset of 100 sequences (all other components fixed). Without such an ablation, the specific benefit attributed to cluster-specific sequence reuse is not isolated, and the observed gains could be due to the coreset size, the synergy-based initialization, or the test-time selection with Oz fallback. This is a load-bearing gap for the central claim.
minor comments (5)
  1. [§5.3] The text contains literal placeholder values '[e.g., 0.75]' and '[e.g., 0.55]' for the Silhouette scores. Actual measured values must be reported; the figure alone is not sufficient.
  2. [Title] The PDF header title ('GRACE: Globally-Seeded Representation-Aware Cluster-Specific Evolution for Compiler Auto-Tuning') differs from the abstract/title line ('GRACE: Cluster-Specific Sequence Reuse for Compiler Auto-Tuning'). The title should be unified.
  3. [§4.3, §3.2] Several training hyperparameters are missing: the contrastive temperature τ, batch size, the value of k_top for selecting candidate sequences, the GA population size, and the network architecture of the encoder/projection head. Section 4.3 gives k=100 and 50 generations but not the remaining parameters needed for replication.
  4. [§5.1] The reported average OverOz is the unweighted mean of the seven per-dataset averages (Table 2), not a per-program average. This should be stated explicitly, since dataset sizes range from 11 to 121 programs.
  5. [§2] Typo: 'reviews reviews the evolution' should be 'reviews the evolution'.

Circularity Check

0 steps flagged

No circularity: central OverOz claims are measured on held-out programs with a fixed offline coreset; self-citation to CFSAT is a baseline and source of inspiration, not load-bearing.

full rationale

No circular step meets the evidentiary bar. GRACE's main claimed result—10.09%/10.19% average OverOz improvement over opt -Oz—is an empirical evaluation of a fixed 100-sequence coreset on 335 held-out test programs (Table 1). The weighted-score objective, synergy graph, embeddings, k-means clusters, and evolved coreset are all constructed from the 19,603 training programs before test evaluation; the test programs are not used to fit DISTRIBUTION_SCORE_WEIGHTS, the pass pool, the cluster centroids, or the GA fitness. Test-time coreset selection and the opt -Oz fallback are the deployed method itself, not a post hoc fit that guarantees the reported number. The ablation that replaces the contrastive embedding with PairVec (10.09% vs 9.25%, Section 5.3) is an independent empirical comparison. The only self-citation is CFSAT [28], which is used as a comparison baseline (Table 2) and as the inspiration for pass-synergy analysis; GRACE reimplements the synergy graph (Algorithm 1) and measures its contribution in Section 5.4, so the self-citation is not load-bearing. No uniqueness theorem or ansatz is imported from self-cited work. Therefore the derivation chain is not circular. I note separately, as correctness/completeness concerns rather than circularity: the abstract's execution-oriented claims (26.84%/27.54% cycle-count reduction and polybench/cBench speedups) are absent from Sections 4–5; Section 5.3 contains placeholder text ('[e.g., 0.75]'); and the headline OverOz numbers are internally inconsistent (abstract 9.92%/10.30% vs. body 10.09%/10.19%). These issues weaken support for the strongest advertised claims but do not make the reported code-size experiments circular.

Axiom & Free-Parameter Ledger

5 free parameters · 4 axioms · 0 invented entities

The central claim rests on several unproven transfer assumptions and hand-set hyperparameters; none are fitted to test data, but they are not independently justified either. No new physical or conceptual entities are postulated; the coreset sequences are artifacts of the search procedure, not invented explanatory entities.

free parameters (5)
  • k (number of clusters / coreset sequences) = 100
    Hand-chosen; controls trade-off between test-time evaluation cost and specialization; no sensitivity analysis reported.
  • DISTRIBUTION_SCORE_WEIGHTS = {Avg: 0.75, Std: 0.1, NegRate: 0.15}
    Hand-set weights used in candidate ranking and GA fitness; no ablation across weight choices.
  • GA generations = 50
    Fixed generation count; population size and genetic operator rates are not fully specified.
  • Contrastive temperature and training hyperparameters = not reported
    Kernel temperature in the distance contrastive loss and network training details are omitted, affecting the learned embeddings.
  • k_top (top candidate sequences) = not reported
    Number of top sequences forming C_seq and the pass pool; not stated in the paper.
axioms (4)
  • domain assumption Programs close in learned embedding space respond similarly to identical pass sequences
    Central transfer premise; Sections 3.2-3.3 cluster by embeddings and then assume one evolved sequence serves the cluster. Validated only indirectly via silhouette/DBI and one ablation.
  • domain assumption Pairwise pass synergy measured on training programs generalizes to unseen programs
    The synergy graph G_co in Section 3.1, built from training pairs, is used to generate candidates and the pass pool; noisy edges would restrict search away from good passes.
  • domain assumption Random pass-sequence augmented programs are semantically valid positives for contrastive learning
    Positive pairs (P_i, P'_i) in Section 3.2 rely on random compiler transformations preserving optimization-relevant semantics; if not, embeddings encode transformation artifacts.
  • domain assumption LLVM IR instruction count is a meaningful proxy for code size and, via the abstract's extension, for execution performance
    All training, fitness, and headline metrics use IR instruction count; the abstract's cycle-count and speedup claims require an additional, unstated cost model.

pith-pipeline@v1.3.0-alltime-deepseek · 18075 in / 16008 out tokens · 136256 ms · 2026-08-04T09:47:29.712224+00:00 · methodology

0 comments
read the original abstract

Compiler auto-tuning aims to improve optimization quality beyond fixed compiler heuristics, but existing approaches often face a trade-off between effectiveness and deployability. Iterative compilation can discover strong program-specific optimization sequences, yet its search cost is often prohibitive for practical reuse. Learning-based methods reduce tuning overhead, but their effectiveness depends on how well optimization knowledge transfers to unseen programs. Recent coreset-based methods improve this trade-off, but they typically either still rely on relatively large test-time search or assume that a single global coreset can serve all programs well. We present GRACE, a compiler auto-tuning framework based on \emph{cluster-specific sequence reuse}. GRACE constructs a small reusable sequence coreset for each group of similar programs by combining global pass synergy analysis, optimization-response-guided program organization, and cluster-specific evolutionary search. At deployment time, it evaluates a small coreset on the target program and optionally performs lightweight refinement within a restricted search space, yielding bounded overhead. We evaluate GRACE on seven benchmark datasets using LLVM 10.0.0 and LLVM 18.1.6. For code-size optimization, GRACE reduces LLVM IR instruction count by 9.92\% and 10.30\% on average relative to \texttt{opt -Oz}, while requiring less than 1\,s tuning time per program at deployment. Under an execution-oriented objective, GRACE reduces estimated cycle counts by 26.84\% and 27.54\% on average relative to \texttt{opt -O3}, and also yields measurable end-to-end speedups on runnable cBench and polybench programs. These results suggest that offline-constructed, cluster-specific sequence coresets provide a practical balance between optimization quality and cost.

Figures

Figures reproduced from arXiv: 2510.13176 by Chao Zha, Haolin Pan, Jinyuan Dong, Mingjie Xing, Yanjun Wu.

Figure 1
Figure 1. Figure 1: The GRACE framework. and Pass Pool Construction; (2) Contrastive Learning for Program Embeddings and Clustering; (3) Cluster-Specific Coreset Evolution; and (4) Test-Time Application with Refinement. Each stage is elaborated below. 3.1 Global Candidate and Pass Pool Construction The initial stage of GRACE aims to reduce the vast search space of pass sequences and identify a set of generally effective candi… view at source ↗
Figure 2
Figure 2. Figure 2: Distribution of weighted scores for all unique [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Distributions of Performance Characteristics for the [PITH_FULL_IMAGE:figures/full_fig_p009_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: GRACE’s performance and efficiency on LLVM 18.1.6 across seven benchmark suites. (a) Instruction [PITH_FULL_IMAGE:figures/full_fig_p014_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Comparison of clustering quality for Autophase raw features, GRACE’s Contrastive and PairVec using [PITH_FULL_IMAGE:figures/full_fig_p014_6.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

39 extracted references · 5 linked inside Pith

  1. [1]

    Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, et al . 2016. {TensorFlow}: a system for {Large-Scale} machine learning. In12th USENIX symposium on operating systems design and implementation (OSDI 16). 265–283

  2. [2]

    Mohiuddin Ahmed, Raihan Seraj, and Syed Mohammed Shamsul Islam. 2020. The k-means algorithm: A comprehensive survey and performance evaluation.Electronics9, 8 (2020), 1295

  3. [3]

    Jason Ansel, Shoaib Kamil, Kalyan Veeramachaneni, Jonathan Ragan-Kelley, Jeffrey Bosboom, Una-May O’Reilly, and Saman Amarasinghe. 2014. Opentuner: An extensible framework for program autotuning. InProceedings of the 23rd international conference on Parallel architectures and compilation. 303–316

  4. [4]

    David H Bailey, Eric Barszcz, John T Barton, David S Browning, Robert L Carter, Leonardo Dagum, Rod A Fatoohi, Paul O Frederickson, Thomas A Lasinski, Rob S Schreiber, et al. 1991. The NAS parallel benchmarks.The International Journal of Supercomputing Applications5, 3 (1991), 63–73

  5. [5]

    Tal Ben-Nun, Alice Shoshana Jakobovits, and Torsten Hoefler. 2018. Neural code comprehension: A learnable representation of code semantics.Advances in neural information processing systems31 (2018)

  6. [6]

    James Bergstra, Rémi Bardenet, Yoshua Bengio, and Balázs Kégl. 2011. Algorithms for hyper-parameter optimization. Advances in neural information processing systems24 (2011)

  7. [7]

    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 (ICSE). IEEE, 1198–1209

  8. [8]

    Yang Chen, Shuangde Fang, Yuanjie Huang, Lieven Eeckhout, Grigori Fursin, Olivier Temam, and Chengyong Wu

  9. [9]

    Ivan Culjak, David Abram, Tomislav Pribanic, Hrvoje Dzapo, and Mario Cifrek. 2012. A brief introduction to OpenCV. In2012 proceedings of the 35th international convention MIPRO. IEEE, 1725–1730

  10. [11]

    Chris Cummins, Volker Seeker, Dejan Grubisic, Baptiste Roziere, Jonas Gehring, Gabriel Synnaeve, and Hugh Leather

  11. [12]

    Chris Cummins, Bram Wasti, Jiadong Guo, Brandon Cui, Jason Ansel, Sahir Gomez, Somya Jain, Jia Liu, Olivier Teytaud, Benoit Steiner, et al. 2022. Compilergym: Robust, performant compiler optimization environments for ai research. In2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 92–105

  12. [13]

    DeepSeek-AI DeepSeek-AI, Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, Peiyi Wang, Xiao Bi, Xiaokang Zhang, Xingkai Yu, Yu Wu, Z.F. Wu, Zhibin Gou, Zhihong Shao, Zhuoshu Li, Ziyi Gao, Aixin Liu, Bing Xue, Bingxuan Wang, Bochao Wu, Bei Feng, Chengda Lu, Chenggang Zhao, Chengqi Deng, Chenyu Zhang, Chong Ru...

  13. [14]

    Meta large language model compiler: Foundation models of compiler optimization.arXiv preprint arXiv:2407.02524 (2024)

  14. [15]

    Grigori Fursin. 2009. Collective Tuning Initiative: automating and accelerating development and optimization of computing systems. InGCC Developers’ Summit

  15. [16]

    Unai Garciarena and Roberto Santana. 2016. Evolutionary optimization of compiler flag selection by learning and exploiting flags interactions. InProceedings of the 2016 on Genetic and Evolutionary Computation Conference Companion. 1159–1166

  16. [17]

    Matthew R Guthaus, Jeffrey S Ringenberg, Dan Ernst, Todd M Austin, Trevor Mudge, and Richard B Brown. 2001. MiBench: A free, commercially representative embedded benchmark suite. InProceedings of the fourth annual IEEE international workshop on workload characterization. WWC-4 (Cat. No. 01EX538). IEEE, 3–14

  17. [18]

    Chaoyi Deng, Jialong Wu, Ningya Feng, Jianmin Wang, and Mingsheng Long. 2024. CompilerDream: Learning a Compiler World Model for General Code Optimization.arXiv preprint arXiv:2404.16077(2024)

  18. [19]

    Ruobing Han and Hyesoon Kim. 2024. Exponentially expanding the phase-ordering search space via dormant information. InProceedings of the 33rd ACM SIGPLAN International Conference on Compiler Construction. 250–261

  19. [20]

    Yuko Hara, Hiroyuki Tomiyama, Shinya Honda, Hiroaki Takada, and Katsuya Ishii. 2008. Chstone: A benchmark program suite for practical c-based high-level synthesis. In2008 IEEE International Symposium on Circuits and Systems (ISCAS). IEEE, 1192–1195

  20. [21]

    Davide Italiano and Chris Cummins. 2024. Finding Missed Code Size Optimizations in Compilers using LLMs.arXiv preprint arXiv:2501.00655(2024)

  21. [22]

    Ameer Haj-Ali, Qijing Jenny Huang, John Xiang, William Moses, Krste Asanovic, John Wawrzynek, and Ion Stoica

  22. [23]

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

  23. [24]

    Hugh Leather and Chris Cummins. 2020. Machine learning in compilers: Past, present and future. In2020 Forum for Specification and Design Languages (FDL). IEEE, 1–8

  24. [25]

    Youwei Liang, Kevin Stone, Ali Shameli, Chris Cummins, Mostafa Elhoushi, Jiadong Guo, Benoit Steiner, Xiaomeng Yang, Pengtao Xie, Hugh James Leather, et al. 2023. Learning compiler pass orders using coreset and normalized value prediction. InInternational Conference on Machine Learning. PMLR, 20746–20762

  25. [26]

    Hongzhi Liu, Jie Luo, Ying Li, and Zhonghai Wu. 2021. Iterative compilation optimization based on metric learning and collaborative filtering.ACM Transactions on Architecture and Code Optimization (TACO)19, 1 (2021), 1–25

  26. [27]

    Aaron Jaech, Adam Kalai, Adam Lerer, Adam Richardson, Ahmed El-Kishky, Aiden Low, Alec Helyar, Aleksander Madry, Alex Beutel, Alex Carney, et al. 2024. Openai o1 system card.arXiv preprint arXiv:2412.16720(2024)

  27. [28]

    Haolin Pan, Yuanyu Wei, Mingjie Xing, Yanjun Wu, and Chen Zhao. 2025. Towards Efficient Compiler Auto-tuning: Leveraging Synergistic Search Spaces. InProceedings of the 23rd ACM/IEEE International Symposium on Code Generation and Optimization. 614–627

  28. [29]

    Sunghyun Park, Salar Latifi, Yongjun Park, Armand Behroozi, Byungsoo Jeon, and Scott Mahlke. 2022. SRTuner: Effective compiler optimization customization by exposing synergistic relations. In2022 IEEE/ACM International Symposium on Code Generation and Optimization (CGO). IEEE, 118–130

  29. [30]

    Nadav Rotem and Chris Cummins. 2021. Profile guided optimization without profiles: A machine learning approach. arXiv preprint arXiv:2112.14679(2021). GRACE: Globally-Seeded Representation-Aware Cluster-Specific Evolution for Compiler Auto-Tuning 21

  30. [31]

    Hafsah Shahzad, Ahmed Sanaullah, Sanjay Arora, Ulrich Drepper, and Martin Herbordt. 2024. A Neural Network Based GCC Cost Model for Faster Compiler Tuning. In2024 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 1–9

  31. [32]

    Lili Mou, Ge Li, Lu Zhang, Tao Wang, and Zhi Jin. 2016. Convolutional neural networks over tree structures for programming language processing. InProceedings of the AAAI conference on artificial intelligence, Vol. 30

  32. [33]

    Zheng Wang and Michael O’Boyle. 2018. Machine learning in compiler optimization.Proc. IEEE106, 11 (2018), 1879–1901

  33. [34]

    Chao Zha, Zhiyu Wang, Yifei Fan, Bing Bai, Yinjie Zhang, Sainan Shi, and Ruyun Zhang. 2025. A-NIDS: Adaptive Network Intrusion Detection System Based on Clustering and Stacked CTGAN.IEEE Transactions on Information Forensics and Security(2025)

  34. [35]

    Mingxuan Zhu, Dan Hao, and Junjie Chen. 2024. Compiler Autotuning through Multiple-phase Learning.ACM Transactions on Software Engineering and Methodology33, 4 (2024), 1–38

  35. [37]

    S VenkataKeerthy, Rohit Aggarwal, Shalini Jain, Maunendra Sankar Desarkar, Ramakrishna Upadrasta, and YN Srikant

  36. [38]

    Ir2vec: Llvm ir based scalable program embeddings.ACM Transactions on Architecture and Code Optimization (TACO)17, 4 (2020), 1–27

  37. [2012]

    Deconstructing iterative optimization.ACM Transactions on Architecture and Code Optimization (TACO)9, 3 (2012), 1–30

  38. [2020]

    Autophase: Juggling hls phase orderings in random forests with deep reinforcement learning.Proceedings of Machine Learning and Systems2 (2020), 70–81

  39. [2025]

    (Jan 2025)

    DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. (Jan 2025)