RepoOMP: Repository-Aware Hotspot OpenMP Parallelization via Dependency-Aware Context Reduction

Ke Gao; Ling Li; Shaohui Peng; Yongjie Qian; Zhibin Zhang

REVIEW 3 major objections 4 minor 25 references

RepoOMP: Repository-Aware Hotspot OpenMP Parallelization via Dependency-Aware Context Reduction

T0 review · 3 major / 4 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 RepoOMP recovers hidden dependency evidence before asking an LLM to add OpenMP, accepting 372 of 951 profiled hotspots with a median 2.25x speedup and roughly half the token cost of an unstructured agent.

desk verdict RepoOMP is a genuinely useful hybrid system with a transparent evaluation, but the funnel counts don't reconcile and the per-hotspot validation trail is incomplete; worth a serious referee once the numbers are fixed. read the letter →

arxiv 2608.05855 v1 pith:KCOJFEK6 submitted 2026-08-06 cs.DC

Yongjie Qian , Ke Gao , Zhibin Zhang , Shaohui Peng , Ling Li This is my paper · ORCID

classification cs.DC

keywords OpenMPparallelizationhotspotoptimizationdependencyrecoveryLLMcodegenerationrepository-scaleprogramanalysisstructuredcontexthybridrule-agentsystem

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 argues that the reason OpenMP auto-parallelization fails on mature repositories is not a lack of transformation skill but a lack of evidence: whether a loop is safe and profitable to parallelize usually depends on non-local facts such as transitive callees, file-scope variables, and shared-state writes. RepoOMP therefore inserts an explicit evidence-recovery stage before generation, builds a repository-wide dependency-and-performance graph, and routes each hotspot to deterministic rules, an LLM agent, or a conservative skip based on propagated risk. The claimed payoff is a system that parallelizes far more hotspots than rule-based tools while being far more stable and token-efficient than unstructured LLM agents. On 951 profiled hotspots across NPB, BOTS, FFmpeg, NCNN, and GROMACS, the paper reports that 372 pass compilation, workload-specific checks, and positive speedup, including 330 real-world hotspots with median 2.25x speedup, and that on nine detailed real-world kernels it beats the Claude Code baseline by 18--28% in speedup while cutting agent-side token cost by 47--68%.

What carries the argument

The central object is the Multi-granularity Attributes Performance graph (MAP), a directed property graph with repository, file, and function nodes and control-flow plus data-dependency edges, augmented with runtime hotspot attributes and shared-state access summaries. Its job is to make the non-local evidence that governs parallel safety explicit before generation: it records which callees write file-scope state, which globals a loop touches, and which transitive blockers like I/O or serial control constrain a candidate. The Rule-Agent Router then propagates these blocker attributes bottom-up along the call graph so that a caller inherits the risk of its descendants, and the Structured Transformation Context (STC) serializes the target span, visible shared-state definitions, callee summaries, and a constraint block into a fixed five-field prompt template so the LLM reasons over dependency facts rather than raw repository text.

What would settle it

Run the nine accepted real-world kernels under ThreadSanitizer with a much larger thread count and multiple distinct inputs while exercising the same output checks: if any of the 330 accepted transformations exhibits an unsynchronized read-write race that changes program output on an input or schedule not covered by the original validation suite, the acceptance oracle is insufficient and the reported safety statistics overstate correctness. A cheaper partial check is to count, for each accepted patch, the number of TSan warnings that are introduced by the patch itself rather than pre-existing in the original code.

Watch

Extended reading notes

Core claim

The central claim is that hotspot-oriented OpenMP parallelization in repository contexts is best treated as an evidence-recovery problem rather than a code-generation problem: the decisive dependency facts usually live outside the loop being transformed, so the system that survives is the one that recovers, propagates, and compresses those facts before any directive is written. RepoOMP operationalizes this claim with a three-stage pipeline: a Multi-granularity Attributes Performance graph (MAP) records hotspot timing, call relations, and shared-state access summaries; a Rule-Agent Router propagates blocker attributes bottom-up along the call graph and routes each candidate to a deterministic rule engine, an LLM agent with a bounded Structured Transformation Context (STC), or a conservative skip; and a verification loop accepts only transformations that compile, pass workload-specific executable checks, and show positive speedup. The paper reports that this workflow accepts 372 of 951 profiled hotspots, of which 330 come from FFmpeg, NCNN, and GROMACS, with median 2.25x speedup, and that on the nine detailed accepted real-world kernels RepoOMP achieves a mean 5.25x speedup with zero build-failure/wrong-answer cells while the unstructured Claude Code baseline incurs 26 such cells.

Load-bearing premise

The load-bearing premise is that passing compilation, workload-specific executable checks, and positive speedup on the tested inputs is sufficient evidence that a transformation is safe and semantically preserved, while the paper itself concedes in Section 5 that acceptance is not a proof of race freedom, schedule-independent correctness, or exhaustive preservation.

Editorial extensions

If this is right

If acceptance under compilation, workload checks, and positive speedup is trusted, RepoOMP roughly triples the number of parallelizable hotspots recovered compared with the rule-only branch while eliminating the build-failure and wrong-answer outcomes that dominate the unstructured agent baseline.
The hybrid routing means deterministic rules remain the cheap high-confidence path, so repositories with many regular reduction-style loops should see low token cost and high acceptance simultaneously.
The token waste of the unstructured agent is largely retry churn: the paper reports cases where the baseline spends millions of tokens and still ends in build failure or wrong answer, whereas RepoOMP keeps agent-side usage stable across three different LLM backbones.
The MAP abstraction is not OpenMP-specific, so the same evidence-recovery workflow could be reused to gate other risky whole-repository transformations that depend on cross-file dependency facts.
Because the accepted-set distribution is disclosed rather than cherry-picked, the median 2.25x across 330 real-world hotspots indicates the approach does not depend on a few spectacular kernels.

Reading between the lines

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

Editorial inference: the decisive comparison the paper does not run is an oracle-targeted one where a human hands each tool the exact loop to parallelize; the reported rule-based baselines are evaluated on the harder command-level interface, so the 8x-9x versus 1.4x-1.5x gap partly reflects task interface rather than raw transformation ability.
Editorial inference: a natural stress test of the paper's thesis would be to feed RepoOMP's STC to the unstructured baseline and vice versa; if the evidence package alone transfers the gain, the paper's mechanism is confirmed, whereas if the agent still fails, routing and verification play a larger role than claimed.
Editorial inference: the bounded-context design suggests a scaling law opposite to common agent practice: for dependency-sensitive code transformations, more retrieved context should degrade correctness before it improves it, so the optimal policy is to compress to facts rather than enlarge windows.
Editorial inference: the reported ThreadSanitizer reductions (21--49 percent fewer warnings) suggest the STC may also serve as a weak race-prevention filter, a property that could be tested independently by counting newly introduced TSan warnings per transformation before acceptance.

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.

Desk Editor's Note

read the letter

RepoOMP is a genuinely useful system. It recovers repository-level dependency evidence before generating OpenMP pragmas, routes simple loops to deterministic rules and harder ones to an LLM, and compresses context to the facts that matter. The evaluation is broad and more transparent than most in this area: 951 profiled hotspots across NPB, BOTS, FFmpeg, NCNN, and GROMACS, 372 accepted under compile/workload/speedup checks, with the funnel, accepted-set distributions, repeated-run spreads, ablations, and explicit limitations all disclosed. The token-cost reduction (47–68% vs the unstructured Claude Code baseline) and the stability evidence (CV under 1% on all nine detailed kernels) are real and worth building on.

The main soft spot is arithmetic. Section 4.1 says 817 hotspots entered attempted transformation, but Table 14 sums to 789. RQ2 says 212 no-speedup rollbacks, but the table sums to 184. The GROMACS row also disagrees with itself: outcome counts sum to 140 while attempted is listed as 137. These discrepancies change the headline acceptance rate from 45.5% to 47.2%. They are likely transcription errors, but they need to be reconciled before the counts can be trusted.

Second, the per-hotspot validation oracle for the 330 accepted real-world hotspots is not specified. Table 3 gives detailed oracles for the nine case-study workloads and for NPB/BOTS, but no table maps each accepted hotspot to a specific executable check, input asset, or golden baseline. The paper's Section 5 disclaimer is honest, but it does not replace a missing per-hotspot mapping. If a hotspot was accepted under a workload command whose output path does not exercise it, the check is vacuous.

The nine detailed kernels are deliberately selected; the paper discloses this and gives within-repository ranks, which mitigates the concern. The AutoPar/Polly baselines run under a different task interface, so the comparison is more about protocol suitability than transformation quality; the paper is explicit about this too. The baseline speedup below 1.0 in Table 10 is not a flaw, since the acceptance rule applies only to RepoOMP's own outputs.

Overall, the design is credible and the limitations are stated rather than hidden. The count inconsistencies and the missing per-hotspot oracle mapping are genuine reproducibility soft spots. This paper deserves a serious referee; I would send it to review with a request for a full artifact and reconciled funnel numbers.

Referee Report

3 major / 4 minor

Summary. This paper proposes RepoOMP, a hybrid workflow for OpenMP parallelization of hot loops in large code repositories. It constructs a Multi-granularity Attributes Performance graph (MAP) from a compilation database and syntactic analysis, routes each hotspot to a deterministic rule engine or an LLM agent through a Rule-Agent Router, and compresses the evidence into a Structured Transformation Context (STC). Generated transformations are accepted only if they compile, pass workload-specific executable checks, and show positive speedup. The evaluation reports 372 accepted hotspots out of 951 profiled, including 330 real-world hotspots from FFmpeg, NCNN, and GROMACS, with a median accepted-set speedup of 2.25x; average speedups of 8.23x on NPB and 8.96x on BOTS; and, for nine selected real-world kernels, a cross-backbone mean speedup of 5.25x and reduced agent-side token cost relative to an unstructured Claude Code baseline.

Significance. If the quantitative claims survive repair, this is a valuable systems contribution: the paper identifies a real evidence-recovery gap, proposes an inspectable three-stage architecture, and evaluates it over a large 951-hotspot funnel with explicit disclosure of accepted-set distributions, repeated-run spreads, ablation results, and limitations. The matched-backbone protocol, token accounting, and the authors' willingness to state what the evaluation does not establish are notable strengths. However, the headline acceptance statistics currently rest on internally inconsistent funnel counts and on an unspecified per-hotspot validation mapping for the 330 accepted real-world hotspots; until those are supplied, the central quantitative claims are not reproducible from the manuscript.

major comments (3)

[Section 4.1 / Table 14] The hotspot funnel is internally inconsistent. Section 4.1 states that 817 hotspots enter attempted transformation, but the Attempted column of Table 14 sums to 789 (67+10+461+114+137). Section 4.3 reports 212 no-speedup rollbacks, while the RB column of Table 14 sums to 187. For the real-world rows, Section 4.1 reports 110 workload-check failures and 157 no-speedup rollbacks, but Table 14 sums to 100 check failures and 170 rollbacks for those rows. Table 14's GROMACS outcome cells sum to 140 while the Attempted column lists 137. These discrepancies change the headline acceptance rate from 372/817 = 45.5% to 372/789 = 47.2% and mean the current counts do not support the reported acceptance statistics. Please reconcile the denominator and all failure-mode counts, and identify which table or text is authoritative.
[Section 3.5 / Table 3] The per-hotspot validation oracle for the 330 accepted real-world hotspots is not specified. Table 3 defines oracles for the nine detailed kernels and for the NPB/BOTS suites, and Table 5 gives workload command fragments, but no table or statement maps each of the remaining real-world hotspots to a specific executable check, input asset, golden baseline, or oracle. If a hotspot is accepted under a workload command whose output path does not exercise it, the workload-specific check is vacuous and acceptance collapses to compilation plus positive speedup. The Section 5 caveat that acceptance is not proof of race freedom does not repair the missing mapping. Please provide, for every accepted real-world hotspot, the workload command, input, oracle, and tolerance used, or explicitly restrict the accepted-set claims to the nine kernels for which oracles are defined.
[Abstract / Section 4.2 / Tables 10–11] The headline token-cost and speedup-improvement figures for the nine detailed kernels are not directly supported by the reported tables. The Claude Code baseline averages 111.1k tokens, while the RepoOMP variants average 58.7k, 50.6k, and 66.4k tokens, giving reductions of about 47%, 54%, and 40%, not 47–68%. Similarly, the abstract's 18–28% speedup improvement range does not match the reported means: 4.94x/4.17x is 18% and 5.34x/4.17x is 28%, but 5.46x/4.17x is 31%. Please state the exact computation for these ranges or correct the abstract and Section 4.2.

minor comments (4)

[Section 4.1] The sentence 'For the 712 attempted real-world transformations, Table 16 reports...' appears to refer to the hotspot funnel, which is Table 14; Table 16 is the ablation funnel. Please fix the cross-reference.
[Section 4.6.1 / Figures 3–4] The No-Router and No-STC ablation variants are shown only graphically; please provide numeric funnel rows for these variants, as is done for Flat-Ctx, Agent-Only, and Rule-Only in Table 16.
[Table 3] The tolerance cells use the formatting '10 −5' and '10 −4'; please format these as 10^-5 and 10^-4 for readability.
[Section 3.4] The STC construction uses LLM-generated summaries of the relevant MAP subgraph; no quality control or fallback for incorrect summaries is described. A sentence on how summary errors are detected or bounded would clarify the verification story.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation; accepted-set speedups are positively selected by the explicitly disclosed acceptance rule, with no fitted parameter or self-citation chain doing load-bearing work.

full rationale

RepoOMP is an empirical systems paper whose claims are validated by external execution rather than derived from assumptions that already encode the conclusions. The acceptance rule in Section 3.5 and Table 3—compile, pass workload-specific executable checks, and show positive speedup—does make the reported accepted-set speedup distributions positive for the accepted subset by construction, but the rule is stated explicitly and the full funnel is disclosed in Table 14, so this is a transparent selection criterion rather than a fitted parameter renamed as a prediction. MAP, STC, and the Rule-Agent Router are presented as deterministic engineering heuristics with inspectable intermediates, not as conclusions forced by a self-citation or a uniqueness theorem. Citations to prior work (e.g., MORepair, ToolGen) are contextual related work and do not carry the paper's quantitative claims. The paper's own Section 5 limitations—acceptance is not proof of race freedom, schedule-independent correctness, or exhaustive semantic preservation—are honest scope boundaries, not circular moves. The funnel-count inconsistencies (817 vs 789 attempted; 212 vs 184 rollbacks) and the absence of a per-hotspot oracle mapping for all 330 accepted real-world hotspots are reproducibility and validity concerns, not circularity. No step satisfies the quoted-evidence standard for circular reduction, so the correct finding is no significant circularity.

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

The paper rests on engineering assumptions rather than fitted constants. The main free parameters are evaluation thresholds (5% hotspot cutoff, retry budget, 16-thread headline setting). The critical domain assumptions are that MAP summaries, LLM-generated STC callee summaries, and workload-specific checks capture enough dependency and correctness evidence to keep transformations safe. MAP, STC, and the router are invented system components whose only evidence is the paper's own evaluation.

free parameters (3)

Hotspot runtime cutoff = 5% of total runtime
Chosen threshold used in Section 4.1 to define profiled hotspots; changing it changes the 951-hotspot funnel and the accepted-set denominators. It is a conventional profiling threshold, not fitted to optimize the reported result.
Retry budget = 3 attempts per hotspot
Matched-retry protocol from Section 4.1; caps agent iterations and directly shapes the BF, WA, token, and wall-clock counts in Tables 6 through 11 and Table 14.
Headline thread count = 16 threads
The reported performance and token tables use 16 threads as the primary configuration. The paper also reports sweeps at 1, 32, and 64 threads, but the headline averages are tied to this chosen setting.

assumptions (4)

domain assumption MAP dependency summaries are complete enough for OpenMP safety decisions
The router, STC construction, and agent instructions all assume that the Bear compilation database plus tree-sitter extraction captures the transitive callees, globals, and shared-state writes that determine parallel safety (Sections 3.2 to 3.4). Missing dependencies would let unsafe transformations through.
domain assumption Workload-specific executable checks are sufficient evidence of correctness
The acceptance definition in Section 3.5 and Table 3 equates passing MD5, PSNR, accuracy, or energy-drift checks with acceptable semantic preservation. The paper explicitly acknowledges this is not proof of race freedom or exhaustive semantic preservation, making this a load-bearing assumption.
domain assumption LLM-generated callee summaries in STC are faithful
Section 3.4 uses an LLM to summarize transitive call-chain nodes into short dependency descriptions. If those summaries omit or distort a shared write, the agent's bounded context would hide the very evidence the system exists to expose.
domain assumption Profiling with standard tools gives representative hotspots
The paper states in Section 5 that the profiling phase depends on representative executions and tools such as gprof. Unrepresentative workloads would misrank hotspots and change which loops enter the transformation funnel.

invented entities (3)

MAP (Multi-granularity Attributes Performance graph)
purpose: Repository-level abstraction over hotspots, call relations, dependency edges, and shared-state summaries that drives routing and STC construction.
MAP is an internal data structure with no falsifiable handle outside the paper; its value is assessed only through downstream acceptance rates, speedups, and ablations.
STC (Structured Transformation Context)
purpose: Per-target compressed prompt context containing the target span, shared-state definitions, callee summaries, and constraint blocks.
STC is a serialization format internal to RepoOMP; the paper does not provide an external benchmark by which STC fidelity can be independently measured.
Rule-Agent Router
purpose: Three-way routing heuristic that sends high-confidence candidates to rules, middle-confidence candidates to the LLM, and low-confidence candidates to conservative handling.
The router is a deterministic engineering heuristic; its thresholds are inspectable but not validated against an independent oracle or a learned baseline.

how reviews work

0 comments

Cite this review

Pith. "Pith review of RepoOMP: Repository-Aware Hotspot OpenMP Parallelization via Dependency-Aware Context Reduction." pith.science (2026). https://pith.science/paper/KCOJFEK6

@misc{pith2026260805855,
  author       = {Pith},
  title        = {Pith review of: RepoOMP: Repository-Aware Hotspot OpenMP Parallelization via Dependency-Aware Context Reduction},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KCOJFEK6}},
  note         = {Machine review of arXiv:2608.05855}
}

abstract

OpenMP parallelization of hotspots in mature repositories remains difficult because loop safety and optimization payoff often depend on non-local evidence. Rule-based tools under-parallelize when legality is not locally provable, while agent-based approaches become unstable when retrieval misses decisive dependencies or includes irrelevant code. We present RepoOMP, a hybrid framework that recovers parallelization-relevant evidence before generation. RepoOMP builds a Multi-granularity Attributes Performance graph (MAP), routes hotspots between deterministic rules and an LLM agent, and constructs a Structured Transformation Context (STC) that exposes dependency facts without flooding the model with unrelated repository text. We evaluate RepoOMP on 951 profiled hotspots from NPB, BOTS, FFmpeg, NCNN, and GROMACS. Under compilation, workload-specific checks, and positive speedup, 372 hotspots are accepted, including 330 real-world repository hotspots. RepoOMP achieves average speedups of $8.23\times$ on NPB and $8.96\times$ on BOTS. For the nine detailed real-world kernels used in matched-backbone and robustness analyses, RepoOMP reaches a cross-backbone mean of $5.25\times$, improves speedup by 18--28\%, and reduces agent-side token cost by 47--68\% relative to the unstructured Claude Code baseline. Across 330 accepted real-world hotspots, median speedup is $2.25\times$. Overall, RepoOMP provides an evidence-guided workflow for hotspot parallelization in repository settings. The open-source repository is available at https://github.com/Qlalq/RepoOMP_Simplified.

Figures

Figures reproduced from arXiv: 2608.05855 by the authors.

**Figure 1.** Running example motivating repository-context evidence recovery. A locally independent-looking loop reaches a hidden [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗

**Figure 2.** Overview of the RepoOMP framework. The workflow consists of three stages: Global Navigation constructs the [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗

**Figure 3.** Ablation study on RepoOMP’s component effective [PITH_FULL_IMAGE:figures/full_fig_p016_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 5.** Figure 5: NPB speedup with varying thread counts on Intel [PITH_FULL_IMAGE:figures/full_fig_p018_5.png]

**Figure 7.** Figure 7: Real-world application speedup with varying thread [PITH_FULL_IMAGE:figures/full_fig_p018_7.png]

**Figure 9.** Figure 9: Claude Code speedup across CPU architectures using [PITH_FULL_IMAGE:figures/full_fig_p019_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

25 extracted references · 20 canonical work pages

[3]

Chong Wang, Jian Zhang, Yebo Feng, Tianlin Li, Weisong Sun, Yang Liu, and Xin Peng

Accessed 2026-04-23. Chong Wang, Jian Zhang, Yebo Feng, Tianlin Li, Weisong Sun, Yang Liu, and Xin Peng. Teaching code llms to use autocompletion tools in repository-level code generation.ACM Transactions on Software Engineering and Methodology, 34(7):1–27,

work page 2026
[6]

Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang

Accessed 2026-04-23. Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang. Hybrid automated program repair by combining large language models and program analysis.ACM Transactions on Software Engineering and Methodology, 34(7):1–28,

work page 2026
[7]

Boyang Yang, Haoye Tian, Jiadong Ren, Hongyu Zhang, Jacques Klein, Tegawendé F

doi: 10.1145/3715004. Boyang Yang, Haoye Tian, Jiadong Ren, Hongyu Zhang, Jacques Klein, Tegawendé F. Bissyandé, Claire Le Goues, and Shunfu Jin. Morepair: Teaching llms to repair code via multi-objective fine-tuning.ACM Transactions on Software Engineering and Methodology, 35(2):1–38,

doi:10.1145/3715004
[12]

Ompar: Automatic parallelization with ai-driven source-to-source compilation

Tal Kadosh, Niranjan Hasabnis, Prema Soundararajan, Vy A V o, Mihai Capota, Nesreen Ahmed, Yuval Pinter, and Gal Oren. Ompar: Automatic parallelization with ai-driven source-to-source compilation. arXiv preprint arXiv:2409.14771,

arXiv
[13]

Quazi Ishtiaque Mahmud, Ali TehraniJamsaz, Hung D Phan, Le Chen, Mihai Capot˘a, Theodore L Willke, Nesreen K Ahmed, and Ali Jannesari

Accessed 2026-04-23. Quazi Ishtiaque Mahmud, Ali TehraniJamsaz, Hung D Phan, Le Chen, Mihai Capot˘a, Theodore L Willke, Nesreen K Ahmed, and Ali Jannesari. Autoparllm: Gnn-guided context generation for zero-shot code parallelization using llms. InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational...

work page 2026
[14]

22 APREPRINT- AUGUST7, 2026 OpenAI

[Accessed: 2025-07-31]. 22 APREPRINT- AUGUST7, 2026 OpenAI. Codex (2025 research -preview for coding agent). Announced May 16,2025; available June 3, 2025 to Plus/Pro/Team users, 2025a. Cloud-based coding agent for multi-task code generation, bug fixing, PR proposals. John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasi...

work page 2025
[15]

Openhands: An open platform for ai software developers as generalist agents

Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. Openhands: An open platform for ai software developers as generalist agents. arXiv preprint arXiv:2407.16741,

arXiv
[16]

Cognition

Accessed 2026-04-23. Cognition. Devin: The first ai software engineer.https://devin.ai/,

work page 2026

Show all 25 references

[17]

Windsurf (Exafunction, Inc.)

Accessed: 2025-12-08. Windsurf (Exafunction, Inc.). Windsurf editor: an agentic ide for ai-native coding. https://windsurf.com/editor,

2025
[18]

Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Vageesh D C, Arun Iyer, Suresh Parthasarathy, Sriram Raja- mani, Balasubramanyan Ashok, and Shashank Shet

[Accessed: 2025-07-31]. Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Vageesh D C, Arun Iyer, Suresh Parthasarathy, Sriram Raja- mani, Balasubramanyan Ashok, and Shashank Shet. Codeplan: Repository-level coding using llms and planning. Proceedings of the ACM on Software En...

2025
[19]

Augmentedcode: Examining the effects of natural language resources in code retrieval models

Mehdi Bahrami, NC Shrikanth, Yuji Mizobuchi, Lei Liu, Masahiro Fukuyori, Wei-Peng Chen, and Kazuki Munakata. Augmentedcode: Examining the effects of natural language resources in code retrieval models. arXiv preprint arXiv:2110.08512,

arXiv
[23]

Accessed: 2025-12-15. Tencent. ncnn: A high-performance neural network inference framework optimized for mobile platforms. https: //github.com/Tencent/ncnn,

2025
[24]

Accessed: 2025-12-15. OpenAI. Gpt-5.1 [large language model]. Accessed December 2025 via https://chat.openai.com, 2025b. Anthropic. Claude 4.5 sonnet [large language model]. Accessed December 2025 via https://claude.ai/,

2025
[25]

Gemini 3 pro experimental [large language model]

Google DeepMind. Gemini 3 pro experimental [large language model]. Accessed December 2025 via https://blog.google/technology/google-deepmind/gemini-model-thinking-updates-march-2025/,

2025
[2002]

Hpc-coder-v2: Studying code llms across low-resource parallel languages

Aman Chaturvedi, Daniel Nichols, Siddharth Singh, and Abhinav Bhatele. Hpc-coder-v2: Studying code llms across low-resource parallel languages. InISC High Performance 2025 Research Paper Proceedings (40th International Conference), pages 1–14, Frankfurt, Germany,

2025
[2011]

Weidong Wang and Haoran Zhu

Citeseer, Citeseer. Weidong Wang and Haoran Zhu. Omp-engineer: Bridging syntax analysis and in-context learning for efficient automated openmp parallelization. arXiv preprint arXiv:2405.03215,

arXiv
[2012]

Par4all: From convex array regions to heterogeneous computing

Mehdi Amini, Béatrice Creusillet, Stéphanie Even, Ronan Keryell, Onig Goubier, Serge Guelton, Janice Onanian McMahon, François-Xavier Pasquier, Grégoire Péan, and Pierre Villalon. Par4all: From convex array regions to heterogeneous computing. InIMPACT 2012: Second Internationa...

2012
[2014]

[Accessed: 2025-07-31]. xteruel. bots: Barcelona openmp task suite.https://github.com/bsc-pm/bots,

2025
[2018]

Zhen Li, Rohit Atre, Zia Ul-Huda, Ali Jannesari, and Felix Wolf

Association for Computing Machinery. Zhen Li, Rohit Atre, Zia Ul-Huda, Ali Jannesari, and Felix Wolf. Discopop: A profiling tool to identify parallelization opportunities. InTools for High Performance Computing 2014: Proceedings of the 8th International Workshop on Parallel To...

2014
[2019]

FFmpeg Developers

[Accessed: 2025-07-31]. FFmpeg Developers. Ffmpeg.https://github.com/FFmpeg/FFmpeg,

2025
[2021]

Accessed 2026-04-23. Mihail. Npb 3.0 openmp c version (unofficial nas parallel benchmarks). https://github.com/ benchmark-subsetting/NPB3.0-omp-C,

2026
[2022]

Xiangyan Liu, Bo Lan, Zhiyuan Hu, Yang Liu, Zhicheng Zhang, Fei Wang, Michael Shieh, and Wenmeng Zhou

Association for Computing Machinery. Xiangyan Liu, Bo Lan, Zhiyuan Hu, Yang Liu, Zhicheng Zhang, Fei Wang, Michael Shieh, and Wenmeng Zhou. Codexgraph: Bridging large language models and code repositories via code graph databases. arXiv preprint arXiv:2408.03910,

arXiv
[2024]

Dan Quinlan and Chunhua Liao

Association for Computing Machinery. Dan Quinlan and Chunhua Liao. The rose source-to-source compiler infrastructure. InCetus users and compiler infrastructure workshop, in conjunction with PACT, volume 2011, page 1, Princeton, NJ, USA,

2011
[2025]

doi: 10.1145/3714462. 21 APREPRINT- AUGUST7, 2026 Hervé Yviquel, Marcio Pereira, Emílio Francesquini, Guilherme Valarini, Gustavo Leite, Pedro Rosso, Rodrigo Ceccato, Carla Cusihualpa, Vitoria Dias, Sandro Rigo, et al. The openmp cluster programming model. InWorkshop Proceedin...

2026 doi
[2026]

Tobias Grosser, Armin Groesslinger, and Christian Lengauer

doi: 10.1145/3735129. Tobias Grosser, Armin Groesslinger, and Christian Lengauer. Polly—performing polyhedral optimizations on a low-level intermediate representation.Parallel Processing Letters, 22(04):1250010,

doi

Pith tools

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

[1] [3]

Chong Wang, Jian Zhang, Yebo Feng, Tianlin Li, Weisong Sun, Yang Liu, and Xin Peng

Accessed 2026-04-23. Chong Wang, Jian Zhang, Yebo Feng, Tianlin Li, Weisong Sun, Yang Liu, and Xin Peng. Teaching code llms to use autocompletion tools in repository-level code generation.ACM Transactions on Software Engineering and Methodology, 34(7):1–27,

work page 2026

[2] [6]

Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang

Accessed 2026-04-23. Fengjie Li, Jiajun Jiang, Jiajun Sun, and Hongyu Zhang. Hybrid automated program repair by combining large language models and program analysis.ACM Transactions on Software Engineering and Methodology, 34(7):1–28,

work page 2026

[3] [7]

Boyang Yang, Haoye Tian, Jiadong Ren, Hongyu Zhang, Jacques Klein, Tegawendé F

doi: 10.1145/3715004. Boyang Yang, Haoye Tian, Jiadong Ren, Hongyu Zhang, Jacques Klein, Tegawendé F. Bissyandé, Claire Le Goues, and Shunfu Jin. Morepair: Teaching llms to repair code via multi-objective fine-tuning.ACM Transactions on Software Engineering and Methodology, 35(2):1–38,

doi:10.1145/3715004

[4] [12]

Ompar: Automatic parallelization with ai-driven source-to-source compilation

Tal Kadosh, Niranjan Hasabnis, Prema Soundararajan, Vy A V o, Mihai Capota, Nesreen Ahmed, Yuval Pinter, and Gal Oren. Ompar: Automatic parallelization with ai-driven source-to-source compilation. arXiv preprint arXiv:2409.14771,

arXiv

[5] [13]

Quazi Ishtiaque Mahmud, Ali TehraniJamsaz, Hung D Phan, Le Chen, Mihai Capot˘a, Theodore L Willke, Nesreen K Ahmed, and Ali Jannesari

Accessed 2026-04-23. Quazi Ishtiaque Mahmud, Ali TehraniJamsaz, Hung D Phan, Le Chen, Mihai Capot˘a, Theodore L Willke, Nesreen K Ahmed, and Ali Jannesari. Autoparllm: Gnn-guided context generation for zero-shot code parallelization using llms. InProceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational...

work page 2026

[6] [14]

22 APREPRINT- AUGUST7, 2026 OpenAI

[Accessed: 2025-07-31]. 22 APREPRINT- AUGUST7, 2026 OpenAI. Codex (2025 research -preview for coding agent). Announced May 16,2025; available June 3, 2025 to Plus/Pro/Team users, 2025a. Cloud-based coding agent for multi-task code generation, bug fixing, PR proposals. John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasi...

work page 2025

[7] [15]

Openhands: An open platform for ai software developers as generalist agents

Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. Openhands: An open platform for ai software developers as generalist agents. arXiv preprint arXiv:2407.16741,

arXiv

[8] [16]

Cognition

Accessed 2026-04-23. Cognition. Devin: The first ai software engineer.https://devin.ai/,

work page 2026