Vinarsky Alexander Department of Compiler Technologies Ivannikov Institute for System Programming (ISP) of the Russian Academy of Sciences Dolgoprudny, Russia, 141701 [email protected]
Abstract
1
The paper investigates the possibility of predicting function-inlining decisions in compact compilers, source-to-source tools, and interpreters where the reuse of GCC or LLVM optimization infrastructure is impractical. The relevance of this work is determined by the need to transfer mature inlining heuristics to systems with limited compiler infrastructure, restricted runtime dependencies, and reduced access to target-specific analysis. Existing production compilers already contain strong inliners, but their decisions depend on internal intermediate representations (IRs), pass ordering, target models, and analysis stacks that are difficult to reproduce in lightweight systems. To overcome these constraints, we propose a portable inlining-prediction framework. Production compiler diagnostics serve as supervision; a separate extractor reconstructs caller-callee callsites, prepares sterile source snippets, normalizes them into a universal AST, optionally lowers them to a lightweight structural IR, and exports scalar features for model training. Thus, a trained predictor can be emitted as ordinary C code without a compiler-runtime dependency. To evaluate the proposed framework, we constructed a dataset comprising 336,938 callsites from fifteen open-source C projects, including 79,287 compiler-reported inline events. A comparison of several tabular models is performed using projectaware validation. Under leave-one-project-out validation, CatBoost reaches ROC-AUC 0.928 and PR-AUC 0.713; after threshold tuning, F1 improves from 0.670 to 0.729 and the false-positive rate drops from 0.192 to 0.084. Feature analysis shows that most signal is concentrated in source locality, explicit inline intent, callee size, side effects, branch and call structure, signature shape, and callsite argument shape. Keywords: compiler optimization, function inlining, machine learning, intermediate representation, portable compilers.
At present, function inlining remains one of the most important local optimizations in optimizing compilers. It replaces a function call with the body of the called function, removes direct call overhead, and may expose additional optimization opportunities to later passes, including constant propagation, dead-code elimination, scalar replacement, and loop optimizations. Its effect is both local and contextual: a profitable inline decision can improve the optimization context, whereas an unprofitable one can increase code size, register pressure, instructioncache pressure, stack usage, and compilation time. Production compilers manage this trade-off with mature cost models that depend on rich internal representations, target-specific information, and extensive engineering experience. However, these mechanisms are effective mainly inside their native compiler infrastructures. For small compilers, experimental frontends, educational compilers, interpreters, or language implementations without advanced intermediate representations, direct reuse of such mechanisms becomes difficult. Therefore, this work studies a different deployment setting. The objective is to learn a compact inline-decision predictor from observed compiler behavior and to export it as a small, self-contained component. The model is not intended to improve GCC or LLVM directly. Instead, compiler diagnostics are used as supervision, and the learned predictor is intended for systems where only limited structural information about the caller, callee, and callsite is available.
IN T
Fot Nikolai Department of Compiler Technologies Ivannikov Institute for System Programming (ISP) of the Russian Academy of Sciences Moscow, Russia, 109125 [email protected]
Introduction
PR
PR E
arXiv:2607.17389v1 [cs.SE] 19 Jul 2026
Portable models as a replacement for industrial heuristics in compiler optimizations
2
Problem Statement
The target problem is binary callsite classification. Given the caller context, callee summary, source-local callsite information, and a small set of structural features, the model estimates whether a production-compiler-like inliner would inline the call. The output is an inline/no-inline hint, not a 1
mandatory transformation. A downstream compiler may still apply conservative guards for unsupported constructs, recursion, large callee bodies, excessive stack growth, or code-size limits. The main difficulty is caused by the portability requirement. Feature extraction must not require LLVM IR, GCC GIMPLE, tree-SSA, target-specific lowering, profile-guided metadata, alias analysis, or pass-manager state. Inference must be possible in a small runtime-free C component. The label source may be a production compiler, but the deployed predictor should be usable by systems closer to TinyCC/TCC, Smaller C, chibicc-like compilers, source-to-source tools, and interpreters with explicit function-call lowering hooks [1, 7, 27]. Thus, the supervision used in this paper should be understood as compiler agreement. A positive label means that the reference compiler reported an inline event under the selected build configuration. A negative label means that the callsite was observed by the scanner but was not matched to such a report. These labels are useful for behavior distillation, but they should not be considered direct proof of runtime profitability.
Architecture of the Proposed Solution
4
IN T
Figure 1 summarizes the intended integration point. A frontend or small compiler supplies a callsite summary and a callee summary. The model returns an inline/no-inline hint before later lowering or backend stages. This placement is deliberately early: it does not require full SSA construction, register allocation, target-specific cost modeling, or profile-guided information. This integration is supported by three main architectural layers. The first layer is scraping: rebuilding real projects with inline diagnostics, parsing positive events, enumerating candidate callsites, and reconstructing caller-callee pairs. The second layer is representation: preparing sterile snippets, normalizing them into a universal AST, lowering them into a lightweight structural IR when possible, and emitting scalar features. The third layer is modeling: training a baseline model, comparing model families, tuning thresholds and feature sets, and exporting the selected predictor as a plain C evaluator.
Existing Solutions
PR
3
expressive, but graph construction and graph inference increase the deployment cost.
Learning-based compiler optimization has several strong predecessors:
4.1
Scraping Layer
The scraping layer obtains labels from compiler feedback. It is intentionally independent of the modeltraining code: the same collected table can be used for CatBoost, LightGBM, random forests, logistic baselines, ablations, or a later handcrafted distilled tree. The diagnostic log is not sufficient by itself, because it gives positive events but not negative candidates, function bodies, signature information, or local callsite structure.
PR E
1. MILEPOST GCC demonstrates that static program features can support optimization choices within GCC [8]. Its feature extractor uses GCCinternal representations such as tree-SSA, RTL, control-flow information, def-use chains, and loop information. Thus, it is an important reference point. Nonetheless, it is not a portable feature contract for small external compilers.
2. MLGO studies machine-learning-guided optimization in LLVM and includes inlining-forsize decisions [26]. MLGO operates within the LLVM optimization pipeline, uses LLVM IR and inliner state, and evaluates the productioncompiler optimization metrics. The present work instead targets a predictor whose features are intentionally close to AST-level, file-level, and callsite-level structure, so that the inference path can later be reproduced outside LLVM.
4.2
Baseline Model Layer
The baseline layer converts each labeled callsite into a feature vector and trains a deployable tabular model. Early proof-of-concept export used a shallow in-repository tree ensemble. The current reference model is CatBoost because it provides strong project-wise ranking quality and consists of oblivious trees that can be represented as static arrays. Random forests and Extra Trees remain important 3. CompilerGym provides benchmark environ- baselines because they are simple tree ensembles ments, action spaces, observation spaces, and and can also be exported as standalone code. reward interfaces for compiler-optimization research [5]. It is useful for experimentation, 4.3 Tuning Layer but it is not itself a compact inline heuristic that can be embedded in a small compiler. Tuning is performed at two levels. Model-family ProGraML represents programs as attributed tuning selects between linear, forest, and boostedmultigraphs with control-flow, data-flow, and tree models. Feature-contract tuning compares comcall-flow edges [4]. Such representations are pact subsets such as core4, core8, core12, core20, 2
Figure 1: Integration strategy. The model consumes callsite and callee summaries and supplies an inline/no-inline hint before later compiler stages.
5
NeuralIR Pipeline
IN T
6
ast_site_no_ir, and the full feature set. Decisionthreshold tuning is separate from model training: a threshold can trade recall for a lower false-positive rate without changing the learned ranking function.
The representation has two layers. The first is a normalized abstract syntax tree. The second is a lightweight structural intermediate representation. This split is the main reason why the framework is not tied to GCC or LLVM.
Scraping
The dataset is built by scraping compiler feedback. Each target project is rebuilt with inline optimization diagnostics enabled. A diagnostic line gives a positive label when the compiler reports that a particular callee was inlined into a caller. The simplified form of the two supported diagnostic styles is shown in Figure 2.
PR E
PR
The normalized AST is meant to be a common source-level vocabulary. It stores only constructs that are useful for inline prediction: functions, calls, returns, loops, switches, branches, declarations, assignments, normalized unary and binary operations, local objects, and visible side-effect patterns. It Figure 3 shows the current scraping framework. discards parser-specific details and many projectThe positive-label parser records the source location, specific constructs. caller, callee, and diagnostic text when these fields are available. A separate source-level scanner then collects callsites from the same project. A callsite Before a snippet is converted to the normalized is removed from the negative pool only when the AST, the extractor builds a minimal caller-callee complete key is matched: the normalized file, line, translation unit. The goal is not to preserve the column, and the caller and callee names. This con- whole project, but rather the local inline decision servative policy avoids name-only matching across context. Figures 4 and 5 show this preparation step. unrelated callsites. After labeling, the extractor reconstructs a local caller-callee pair. It first looks in the event file and function index, then uses bounded fallback source search when necessary. Repeated diagnostics with the same file, caller, and callee are disambiguated by occurrence offset. The corresponding call occurrence inside the caller is then selected for feature extraction.
/* Comment. Comment. Comment. */ #define likely(x) __builtin_expect(!!(x), 1) typedef unsigned long my_size_t; struct request { char *buf; my_size_t len; }; static __attribute__((always_inline)) my_size_t small( struct request *r) { asm volatile("" ::: "memory"); return likely(r->len) ? helper(r->buf, ({ my_size_t n = r->len; n; })) : global_limit; } int caller(struct request *r) { if (small(r) > 4) return slow_path(r); return 0; }
The output of this stage is a model-ready table. Each row represents one callsite. A positive row means that the reference compiler reported an inline event under the selected build configuration. A negative row means that the scanner found the callsite, but it was not matched to such a report. The negative pool can therefore contain unsupported, optimized-away, indirectly called, missed, or merely Figure 4: Example C pair before sterile snippet preparation. unselected calls. 3
(GCC) source.c:123:123: optimized: Inlined callee.callee.123/123 into caller.caller.123/123 which now ,→ has time X and size Y, net change of -Z. (Clang) source.c:123:123: remark: 'callee' inlined into 'caller' with (cost=X, threshold=Y) at callsite ,→ caller:123:123; [-Rpass=inline]
Figure 2: Example GCC and Clang inline optimization diagnostics used as positive label sources.
Compiler inline diagnostics
Positive labels inlined calls Caller--callee pair builder
Callsite scanner (all calls)
Negative labels remaining calls
pycparser + fake libc
IN T
Target C project + build flags
Figure 3: Scraping framework. Positive labels are extracted from compiler inline diagnostics. Negative labels are obtained from remaining callsites after removing known inline events. Both labeled paths are parsed and lowered into a normalized AST and a structural IR before feature extraction. function caller() { small(); <operation_gt> if true, goto label_0; else goto label_1 label_1: slow_path(); <term> label_0: <term> }
PR
typedef int my_size_t; struct request; extern int global_limit; extern int helper(); extern int slow_path();
static my_size_t small(struct request *r) { return helper() ? global_limit : 0; } int caller(struct request *r) { if (small(r) > 4) return slow_path(r); return 0; }
Figure 6: Example structural IR stream for a caller with a call, comparison, branch, and fallback external call.
PR E
Figure 5: Example C pair after preparation. The This intermediate layer exists for feature stabilsnippet keeps caller-callee structure but removes constructs that are not needed by the local predictor. ity. A pure AST can answer many questions, but some structural questions are easier after lowering: how many operation-like actions exist, whether the callsite has local lowered context, how large a simplified basic-block structure is, and whether loop-local context surrounds the call. At the same time, the IR remains much cheaper than LLVM IR or GCC GIMPLE/RTL.
7
The structural IR is not a production compiler IR and is not designed for code generation. It intentionally avoids SSA values, full type propagation, alias analysis, register allocation, target lowering, and rich data-flow edges. Instead, it uses a short action vocabulary over at most three operands per instruction. Function definitions become fdecl/fend; calls become fcall or scall; returns become term; branches and loops introduce labels and jumps; binary and unary expressions become operation counters.
Basic Dataset Analysis
The current corpus contains 336,938 callsites from fifteen C project scrapes: cJSON 1.7.19 [9], FFmpeg 60.32.100 [6], Git 2.54.0 [11], json-c 0.18.99 [12], libevent 2.2.1-alpha-dev [14], libuv 1.52.2-dev [15], Linux [16], Nginx 1.31.1 [20], PostgreSQL [22], Redis 8.8.0 [24], SQLite 3.54.0 [25], tmux next3.7 [17], Valkey 9.1.0 [28], Vim 9.2.286 [19], and Zstd 1.6.0 [18]. Overall, 79,287 callsites are labeled as compiler-inlined, giving a positive rate of 23.53%. Figures 8 and 9 show why project-aware valida4
Figure 7: Portable inline-prediction architecture. Source snippets are parsed into a normalized AST, lowered to structural IR, summarized into a compact numeric feature vector, and evaluated by a tree ensemble.
IN T
Table 1: Multi-project callsite corpus after deduplication. Callsites
Inlined
Inline, %
Explicit inline
Explicit share, %
cJSON FFmpeg Git JSONC Libevent libuv Linux Nginx PostgreSQL Redis SQLite tmux Valkey Vim Zstd
367 54,819 58,221 91 1,889 179 63,786 3,280 119,967 310 12,571 4,206 11,976 311 4,965
0 14,541 6,946 0 0 0 27,641 225 22,421 99 3,628 431 1,299 72 1,984
0.00 26.53 11.93 0.00 0.00 0.00 43.33 6.86 18.69 31.94 28.86 10.25 10.85 23.15 39.96
0 19,977 15,251 7 111 41 44,527 208 30,911 50 2 0 1,321 0 2,184
0.00 36.44 26.20 7.69 5.88 22.91 69.81 6.34 25.77 16.13 0.02 0.00 11.03 0.00 43.99
Total
336,938
79,287
23.53
114,590
34.01
PR
Project
tion is required. The corpus is large, but it is not balanced. PostgreSQL, Linux, Git, and FFmpeg dominate the row count; several smaller projects currently have no positive inline labels.
PR E
inline rate explicit inline share 0
Corpus composition by project
PSQL LINUX GIT FFMPEG SQLLITE VALKEY ZSTD TMUX NGINX LIBEVENT CJSON VIM REDIS LIBUV JSONC
Per-project inline labels and explicit inline usage
PSQL LINUX GIT FFMPEG SQLLITE VALKEY ZSTD TMUX NGINX LIBEVENT CJSON VIM REDIS LIBUV JSONC
10
20
30
40
Percent of rows
50
60
70
Figure 9: Per-project inline label rate and explicitinline usage. Inline-label density varies substantially across projects.
The explicit-inline feature captures programmer intent. Among 114,590 explicitly marked callsites, 64,322 are actually inlined by the compiler, giving 10 10 10 10 Callsites, log scale an inline rate of 56.1%. Among 222,348 callsites without the modifier, 14,965 are inlined, giving an Figure 8: Corpus composition by project. The inline rate of 6.7%. Thus, explicit inline correlargest projects dominate row count, so random sponds to a 49.4 percentage-point increase and an splitting is not enough to evaluate portability. 8.34× relative lift. not inlined inlined
2
3
4
5
5
Effect of explicit programmer inline by project
reference model because it gives strong project-wise ranking quality and can still be represented as static decision-tree tables.
no explicit inline explicit inline
100
60
1.0
40
0.8
20
0.6
Model-family benchmark under project-aware validation
Score
compiler inline rate, %
80
0
PSQ
L
X
LINU
GIT FMPEG QLLITE ALKEY V F S
D
ZST
0.4
T V X C IS AL NGIN LIBEVEN RED LIBU JSON TOT
0.2
Figure 10: Compiler inline rate for explicitly marked and non-explicit callsites. Only projects with explicit-inline rows are shown, plus the total.
Choosing Model
the
0.0
IN T
8
precision recall F0.5
M+
tGB Ligh
neg.
ht
weig
t t t ht es oost ores eigh ightGBM XGBoos gistic weig ExtraTre CatB neg. w omF SGD_lo L neg. Rand ost + ost + o o B B t XG Ca
12: Offline model-family benchmark. Optimal Figure Boosted-tree methods provide the strongest ranking metrics; CatBoost is used as the generated-C deployment candidate.
The full feature space contains 64 numeric and Boolean features. They describe callsite argument structure, callee signature, explicit inline modifiers, AST and IR complexity, side effects, local variables and arrays, operation counts, file locality, and loop context. The full representation is useful for analysis, but not every column should become part of a portable contract. Some features are unstable across projects, such as names and paths. Others duplicate the same compiler-cost signal. The current minimal useful core is an 8-feature contract: same source file, explicit inline intent, side effects, function size, callee call count, branch count, parameter count, and call argument count. This set intentionally removes function names, file names, project names, and other memorization-prone identifiers.
9
Training
False positives
Metric
PR E
PR
The training procedure reads scraper CSV rows, normalizes the selected feature contract, and evaluates project-aware splits. Because projects differ strongly in size and positive rate, source-aware splitting and source-class weighting are preferred over random splitting. The main validation protocol is leave-one-project-out: each project is held out as the test set once, while the model is trained on the remaining projects. The CatBoost deployment candidate uses 100 oblivious trees of depth 6 with learning rate 0.06 and L2 regularization 3.0. The tree structure is exported to JSON and then converted into a plain C evaluator. This keeps the same integration idea— Feature-core ablation 0.95 a small compiler pass supplies scalar features and 4000 0.90 receives an inline/no-inline hint-but replaces the 0.85 previous shallow export with the best verified model 3000 0.80 from the model-family benchmark. 2000 0.75 CatBoost is suitable for this export because all 0.70 precision nodes at the same depth in an oblivious tree use the 1000 recall 0.65 F1 corresponding split [23]. Inference therefore reduces false positives 0.60 0 core4 core8 core12 core20 all to computing a leaf index from a fixed sequence (4) (8) (12) (20) (64) of feature-threshold comparisons and adding the selected leaf value. The generated C file contains Figure 11: Feature-core ablation. The 8-feature no classes, no C++ standard library containers, core gives the best compact F1 and accuracy in the no dynamic allocation, and no CatBoost runtime fixed-configuration comparison, while the 12-feature dependency. extension shifts the trade-off toward recall and more false positives.
10
Evaluation of the Model
Several tabular classifiers were considered: linear models, decision trees, random forests, Extra Trees, The current experiments evaluate agreement with gradient boosting, XGBoost, LightGBM, and Cat- compiler inline diagnostics rather than downstream Boost. CatBoost is used as the current generated-C runtime or code-size improvement. At the default 6
Table 2: Feature-set ablation on the current multi-project corpus. All rows use the same source-aware split, source-class weighting, seed, and compact tree configuration: 24 trees, depth 5, and minimum leaf size 6. Set Feat. Precision Recall F1 FP FN Accuracy core4 core8 core12 core20 all
4 8 12 20 64
0.641 0.676 0.645 0.672 0.659
0.739 0.874 0.918 0.849 0.881
0.686 0.762 0.758 0.750 0.754
3,603 3,647 4,384 3,602 3,963
2,271 1,093 717 1,314 1,036
0.866 0.891 0.883 0.887 0.886
Model
Precision* Recall*
LightGBM + negative weight [13] CatBoost [23] XGBoost + negative weight [3] LightGBM [13] XGBoost [3] CatBoost + negative weight [23] Extra Trees [10] Random Forest [2] SGD Logistic [21]
0.6423 0.661 0.665 0.679 0.661 0.670 0.622 0.619 0.607
IN T
Table 3: Comparison of evaluated model families under leave-one-project-out validation. F1*, F0.5*, and Acc.* use the best threshold selected on the validation predictions. F1*
FP
FN
TP
F1
PR E
TN
Top inline decision drivers
callee.ast.node_count callee.info.ir_count callee.ast.stack_frame_estimate_bytes callee.ast.call_count callee.ast.max_depth callee.signature.has_inline_modifier callee.ast.return_expr_node_count callee.ast.unary_op_count callee.info.bb_count callee.body.return_count callee.ast.binary_op_count caller.callsite.arg_node_count callee.info.compare_ops callee.info.arithmetic_ops callee.ast.branch_count
Table 4: CatBoost confusion matrix under leaveone-project-out validation. 0.500 0.764
Acc.* Deployment note
planation of a tree ensemble, but they are useful for sanity checking. Larger AST depth, more branches per basic block, more parameters, more call arguments, more local variables, loops, assignments, comparisons, logic, and arrays are negatively associated with inlining. Leaf callees and compact returnexpression structure are positively associated.
PR
probability threshold of 0.5, CatBoost obtains ROCAUC 0.9283, PR-AUC 0.713, and F1 0.670. The default threshold favors recall: it captures most compiler-inlined cases but produces many false positives. After tuning the decision threshold to 0.764, F1 improves to 0.729 and the false-positive rate drops from 0.192 to 0.084. This tuned threshold is the one embedded in the generated C predictor.
Threshold
F0.5* FPR*
0.773 0.702 0.665 0.133 0.845 best F1, more false positives 0.667 0.664 0.663 0.105 0.841 generated-C reference 0.629 0.646 0.657 0.098 0.838 low-FPR compromise 0.576 0.623 0.656 0.084 0.836 conservative tuned variant 0.634 0.647 0.656 0.100 0.837 strong boosting baseline 0.597 0.632 0.654 0.090 0.836 conservative CatBoost variant 0.732 0.673 0.641 0.137 0.832 randomized-forest baseline 0.723 0.667 0.637 0.137 0.830 portable ensemble baseline 0.712 0.655 0.625 0.142 0.824 weak linear baseline
FPR
113,125 26,813 3,744 31,055 0.6702 0.1916 128,174 11,764 8,117 26,682 0.7286 0.0841
A separate CatBoost experiment tests the AST/site-only feature contract. It uses a lightweight leave-one-project-out setup and removes all structural-IR-derived counters. Despite this restriction, ast_site_no_ir remains close to the full 0 100 200 300 400 500 600 64-feature CatBoost benchmark: ROC-AUC drops Feature importance from 0.928 to 0.924, PR-AUC from 0.713 to 0.694, and F1 from 0.670 to 0.646. This is important beFigure 13: Top single-feature correlations with the cause the AST/site contract is easier to reproduce inline label. Structural simplicity dominates the outside GCC and LLVM. observed decision surface. Table 5: AST/site-only CatBoost experiment withTuning out structural-IR-derived features. The negative- 11 only FP rate is measured on projects/folds that Tuning has two practical goals. The first is to contain no positive inline labels. choose a model that ranks positive callsites well Set Feat. ROC PR F1 Neg.-only FP under project-aware validation. The second is to ast_site_no_ir 42 0.924 0.694 0.646 0.146 Full CatBoost 64 0.928 0.713 0.670 – select a threshold that makes the exported predictor usable in a compiler-like setting. A low threshold Single-feature correlations are not a complete ex- may maximize recall but can produce too many 7
harmful false positives. A high threshold misses more potential inlines but is safer for downstream integration. The current tuned threshold, 0.764, is selected from validation predictions and embedded in the generated C predictor. The threshold is intentionally treated as a deployment parameter rather than as a property of the feature extractor. Future tuning should be repeated after adding Clang labels, changing the project mix, or moving from compileragreement metrics to downstream runtime and codesize metrics. The roadmap for tuning is to compare core8, core12, ast_site_no_ir, and all under CatBoost and under smaller distilled-tree variants with stricter threshold policies that reduce false positives. Thematic ablations should isolate locality, explicit programmer intent, callee size, side effects, and callsite argument shape.
References [1] Fabrice Bellard and TinyCC contributors. Tiny C Compiler. https://bellard.org/tcc/. Candidate small compiler for patched inlinepredictor integration. [2] Leo Breiman. Random forests. Machine Learning, 45(1):5–32, 2001.
IN T
12
remains stable under these conditions, it can become the primary candidate for cross-language experiments on C/C++, Go, Lua, Python, and later additional compiled-language frontends.
[3] Tianqi Chen and Carlos Guestrin. XGBoost: A scalable tree boosting system. In Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, pages 785–794, 2016.
Conclusion
[4] Chris Cummins, Zacharias V. Fisches, Tal BenNun, Torsten Hoefler, and Hugh Leather. ProGraML: A graph-based program representation for data flow analysis and compiler optimizations. In Proceedings of the 38th International Conference on Machine Learning, volume 139 of Proceedings of Machine Learning Research, pages 2244–2253. PMLR, 2021.
PR
This report presents a framework-centered baseline for portable function-inlining prediction. The pipeline scrapes compiler inline diagnostics, reconstructs labeled caller–callee callsites, prepares sterile source snippets, normalizes them into a universal AST, optionally lowers them to a lightweight structural IR, extracts scalar features, compares deployable tabular models, and exports the selected CatBoost model as plain C. The current multi-project corpus contains 336,938 callsites, of which 23.53% are labeled as compilerinlined. The main empirical result is that nonlinear tree-based models are well suited to the representation. CatBoost gives ROC-AUC 0.928, PR-AUC 0.713, and tuned F1 0.7286, while LightGBM with negative-class weighting gives the highest tuned F1 in the model-family sweep. CatBoost is kept as the generated-C reference because its oblivious trees compile to a compact runtime-free evaluator. The main representation result is that most signal is concentrated in locality, explicit inline annotations, callee size, side effects, branch and call structure, signature shape, and callsite argument shape. The AST/site-only experiment suggests that a useful lower-dependency model is possible even without structural-IR-derived counters. The current evidence supports cross-project agreement with compiler diagnostics, not end-to-end improvement in runtime or binary size. The corpus is imbalanced, negative labels are noisy, and the representation intentionally avoids non-portable names, paths, and compiler-internal state. Therefore, the next version should prioritize compiler integration, benchmark measurements, and validation under additional label sources such as Clang-style optimization remarks. If the AST/site feature contract
PR E
[5] Chris Cummins, Bram Wasti, Jiadong Guo, Brandon Cui, Jason Ansel, Sahir Gomez, Somya Jain, Jia Liu, Olivier Teytaud, Benoit Steiner, Yuandong Tian, and Hugh Leather. CompilerGym: Robust, performant compiler optimization environments for AI research. In Proceedings of the 2022 IEEE/ACM International Symposium on Code Generation and Optimization, 2022. [6] FFmpeg Project. FFmpeg. https://ffmpeg. org/. Accessed as a source project for inlinelabel scraping. [7] Alexey Frunze. Smaller C. https://github. com/alexfru/SmallerC. Candidate small compiler for patched inline-predictor integration. [8] Grigori Fursin, Yuriy Kashnikov, Abdul Wahid Memon, Zbigniew Chamski, Olivier Temam, Mircea Namolaru, Elad Yom-Tov, Bilha Mendelson, Ayal Zaks, Eric Courtois, François Bodin, Phil Barnard, Elton Ashton, Edwin Bonilla, John Thomson, Christopher K. I. Williams, and Michael O’Boyle. Milepost gcc: Machine learning enabled self-tuning compiler. International Journal of Parallel Programming, 39(3):296–327, 2011.
8
[9] Dave Gamble and cJSON contributors. cJSON: Ultralightweight json parser in ansi c. https: //github.com/DaveGamble/cJSON. Accessed as a source project for inline-label scraping. [10] Pierre Geurts, Damien Ernst, and Louis Wehenkel. Extremely randomized trees. Machine Learning, 63(1):3–42, 2006.
Édouard Duchesnay. Scikit-learn: Machine learning in Python. Journal of Machine Learning Research, 12:2825–2830, 2011. [22] PostgreSQL Global Development Group. PostgreSQL. https://www.postgresql.org/. Accessed as a source project for inline-label scraping.
PR
IN T
[11] Git Project. Git. https://git-scm.com/. Ac- [23] Liudmila Prokhorenkova, Gleb Gusev, Aleksandr Vorobev, Anna Veronika Dorogush, and cessed as a source project for inline-label scrapAndrey Gulin. CatBoost: Unbiased boosting ing. with categorical features. In Advances in Neu[12] json-c contributors. json-c: A json implemenral Information Processing Systems, volume 31, tation in c. https://github.com/json-c/ 2018. json-c. Accessed as a source project for inline[24] Redis contributors. Redis. https://redis. label scraping. io/. Accessed as a source project for inline[13] Guolin Ke, Qi Meng, Thomas Finley, Taifeng label scraping. Wang, Wei Chen, Weidong Ma, Qiwei Ye, and Tie-Yan Liu. LightGBM: A highly efficient [25] SQLite Consortium. SQLite. https://www. sqlite.org/. Accessed as a source project for gradient boosting decision tree. In Advances inline-label scraping. in Neural Information Processing Systems, volume 30, 2017. [26] Mircea Trofin, Yundi Qian, Eugene Brevdo, Zinan Lin, Krzysztof Choromanski, and David [14] libevent contributors. libevent: An event notiLi. MLGO: A machine learning guided compiler fication library. https://libevent.org/. Acoptimizations framework, 2021. cessed as a source project for inline-label scraping. [27] Rui Ueyama. chibicc: A small c compiler. https://github.com/rui314/chibicc. Can[15] libuv contributors. libuv: Cross-platform asyndidate educational compiler for integration exchronous i/o. https://libuv.org/. Accessed periments. as a source project for inline-label scraping.
PR E
[16] Linux kernel contributors. Linux kernel. https: [28] Valkey contributors. Valkey. https://valkey. io/. Accessed as a source project for inline//www.kernel.org/. Accessed as a source label scraping. project for inline-label scraping. [17] Nicholas Marriott and tmux contributors. tmux: Terminal multiplexer. https://github.com/ tmux/tmux. Accessed as a source project for inline-label scraping. [18] Meta Platforms, Inc. and Zstandard contributors. Zstandard. https://facebook.github. io/zstd/. Accessed as a source project for inline-label scraping. [19] Bram Moolenaar and Vim contributors. Vim. https://www.vim.org/. Accessed as a source project for inline-label scraping. [20] NGINX Project. NGINX. https://nginx. org/. Accessed as a source project for inlinelabel scraping. [21] Fabian Pedregosa, Gaël Varoquaux, Alexandre Gramfort, Vincent Michel, Bertrand Thirion, Olivier Grisel, Mathieu Blondel, Peter Prettenhofer, Ron Weiss, Vincent Dubourg, Jake Vanderplas, Alexandre Passos, David Cournapeau, Matthieu Brucher, Matthieu Perrot, and 9