P4OMP: Retrieval-Augmented Prompting for OpenMP Parallelism in Serial Code

Azmain Kabir; Wali Mohammad Abdullah

REVIEW 4 major objections 5 minor 18 references

P4OMP: Retrieval-Augmented Prompting for OpenMP Parallelism in Serial Code

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

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

Pith's one-line read P4OMP claims retrieval-augmented prompting yields 100% compile success on parallelizable OpenMP cases.

desk verdict A credible RAG-for-OpenMP pipeline with a plausible headline result, undercut mostly by under-documented evaluation details rather than by a fatal design flaw. read the letter →

arxiv 2506.22703 v1 pith:PNTTFRW6 submitted 2025-06-28 cs.SE cs.AI

Wali Mohammad Abdullah , Azmain Kabir This is my paper

classification cs.SEcs.AI

keywords retrieval-augmentedgenerationOpenMPcodelargelanguagemodelsparallelizationcompilecorrectnesssource-to-sourcetransformationHPC

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

P4OMP is a retrieval-augmented code-generation pipeline that tries to make a general-purpose LLM produce correct OpenMP parallelizations of serial C++ programs. The paper's central claim is that pasting semantically matched OpenMP tutorial excerpts into the prompt eliminates compiled-code failures: P4OMP compiled 102 of 102 parallelizable benchmark programs, while the same model without retrieval compiled only 82 of 108. Six programs were excluded because the authors classify them as relying on non-random-access iterators or thread-unsafe constructs that OpenMP cannot handle. If correct, this means reliable OpenMP annotation can be obtained without fine-tuning, compiler instrumentation, or per-program hand-written prompts, lowering the barrier to parallelizing ordinary serial code.

What carries the argument

The load-bearing mechanism is Retrieval-Augmented Generation over a curated OpenMP tutorial corpus. On each input, P4OMP embeds the serial code, searches a vector index of tutorial segments covering OpenMP 5.2 syntax, data-sharing clauses, reductions, and directive patterns, and inserts the closest matches into the prompt before the model generates code. This grounding gives the model explicit examples of correct clause structure, which the paper argues is what prevents the compile failures that occur when the model is prompted with code alone.

What would settle it

Take the six excluded programs, rewrite each to use index-based traversal or thread-safe containers, and run them through P4OMP; if any compiles and matches the serial output, the 100% figure is overstated. A second test is to recompile all 102 P4OMP outputs with a stricter OpenMP compiler than g++ and check for rejection.

Watch

Extended reading notes

Core claim

The paper's central claim is that retrieval grounding fixes the systematic OpenMP mistakes a plain LLM makes. Given a serial C++ program, P4OMP retrieves the most relevant OpenMP tutorial snippets, places them in the prompt alongside the code, and asks GPT-3.5-Turbo to emit an OpenMP version. Across 108 real-world C++ programs, every one of the 102 cases the authors deem parallelizable compiled successfully, and manual output comparison showed the parallel versions preserved serial semantics; the no-retrieval baseline compiled only 82 of 108. The paper attributes the improvement to the retrieved context suppressing undeclared variables in clauses, invalid reduction types, malformed pragmas, and misuse of collapse and atomic directives.

Load-bearing premise

The six excluded benchmark cases are genuinely unparallelizable under OpenMP, so removing them from the denominator does not inflate the 100% figure.

Editorial extensions

If this is right

If the central claim holds, retrieval-augmented prompting is sufficient to make a general-purpose LLM produce OpenMP code that compiles across a broad benchmark mix, removing the need for per-task prompt engineering or fine-tuning.
The 20 baseline failures are described as systematic, including clause mismanagement, invalid reductions, malformed pragmas, and collapse misuse, so the paper implies retrieval addresses a recurring failure class rather than random noise.
Because the pipeline uses only a tutorial corpus and a prompt template, adding new OpenMP features or directives requires adding corpus content, not retraining the model.
The runtime results suggest the generated pragmas are not only syntactically valid but also effective on compute-bound kernels, with speedups close to linear in places, while memory-bound kernels show expected saturation.

Reading between the lines

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

Editorial inference: the same retrieval-plus-prompt design should transfer to other directive-based parallel models such as OpenACC, SYCL, or CUDA, since the mechanism only needs a structured documentation corpus for the target model.
Editorial inference: 100% compilation success is a syntactic guarantee, not a semantic one; the paper's manual validation on 102 outputs would need to become an automated equivalence check before the approach scales to larger codebases.
Editorial inference: the six excluded cases might be recoverable by first rewriting the code, for example converting iterators to index loops or replacing thread-unsafe containers, suggesting a hybrid LLM-plus-rewriter system could push the effective success rate beyond 102 of 102.

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

Quick take: this is the first RAG-based OpenMP pragma synthesis I know of that's evaluated on a 100+ case benchmark, and the compilation-success gap (102/102 vs 82/102 on the parallelizable denominator) is internally consistent with the described pipeline. The idea is not exotic — retrieve tutorial chunks, stuff them into the prompt — but applying it to OpenMP and testing it at this scale is a legitimate increment over the fine-tuning (OMPGPT), feedback-loop (LASSI), and classifier (PragFormer) lines. I'd credit the authors for building a clean modular pipeline and for reporting runtime scaling on seven kernels; the speedups look sane.

Where the evidence gets soft: the 100% figure leans on excluding six cases as 'unparallelizable' with only category labels as justification. No per-case walkthrough, no compiler diagnostic, no demonstration that alternative restructuring couldn't work. The stress-test note is right that this is a load-bearing exclusion — if even one of those six is actually parallelizable, the headline becomes '102/108 compile, six skipped,' which is a different story. The paper even says 'both systems failed to parallelize' those six, which implies the baseline also got classified as unparallelizable? Actually baseline failed 20, but six excluded. The table says unparallelizable 6/108 for both. Fine. The manual semantic validation (Section IV.B) is also under-specified: one run per case, no variance, no protocol for adjudicating race conditions or scheduling-dependent outputs. And there's no comparison against OMPGPT or LASSI on the same benchmark, so the 'first RAG' novelty is asserted, not demonstrated as better than existing approaches.

That said, none of these soft spots is fatal. The central mechanism — RAG context improves syntactic correctness — is plausible and consistent with the failure analysis. The bigger issue is the paper overclaims 'semantic correctness' from manual execution that isn't documented well enough to reproduce. The missing artifact link is annoying but typical for an anonymous preprint.

Who should read it: people working on LLM-based parallelization and HPC code assistants. It's a solid systems paper that a serious editor should send to review; the reviewers should push for artifact inspection, case-by-case exclusion justification, and a proper semantic-equivalence protocol. I'd not cite the 100% claim in my own work until the repo shows the logs, but I'd cite it as evidence that RAG is a useful cheap baseline for OpenMP generation.

Net: worth engaging, needs revision, not a desk reject.

Referee Report

4 major / 5 minor

Summary. The paper presents P4OMP, a retrieval-augmented prompting pipeline that retrieves OpenMP tutorial chunks and injects them into GPT-3.5-Turbo prompts to parallelize serial C++ loops. The evaluation covers 108 benchmark programs drawn from Stack Overflow, PolyBench, and NAS; the headline result is that P4OMP compiles 102 of 102 cases it classifies as parallelizable, while the baseline compiles 82 of 108. Six cases are excluded as unparallelizable due to non-random-access iterators or thread-unsafe constructs. The paper also reports manual semantic validation of all 102 P4OMP outputs and runtime scaling results for seven compute-intensive kernels on an HPC cluster.

Significance. If the headline results hold, the contribution is a practical and modular recipe: an off-the-shelf LLM, grounded by retrieval over curated OpenMP tutorials, can avoid common syntactic and scoping errors without model fine-tuning or compiler instrumentation. The promised public benchmark suite and tutorial corpus are concrete assets for reproducibility, and the runtime scaling experiments on an HPC cluster are a useful addition. However, the current evidence is insufficient to establish the 100% compilation claim as stated, because the claim depends on the exclusion of six cases and on a manual semantic-validation step whose protocol is not documented. The paper would be strengthened by case-level evidence for the exclusions, a reproducible validation procedure, and repeated-run statistics.

major comments (4)

[V and Table I] The 100% effective success rate is computed over 102 cases after excluding 6 as 'unparallelizable,' but the six cases are never identified by case number and no per-case analysis is provided. The only justification is the category label 'non-random-access iterators or thread-unsafe constructs' in the abstract and Section V. Because the headline claim is defined relative to this denominator, the authors need to list the six cases, show the offending construct, and argue why no valid OpenMP transformation exists (for example, via iterator conversion, loop restructuring, or synchronization). Without this evidence, the effective success rate is not independently checkable from the paper. Table I also lists 'Failures (Fixable) 20/108' and 'Unparallelizable 6/108' separately, but the paper does not state whether the baseline's 20 failures include any of the excluded cases, which affects the comparison.
[IV.B, step 5] The semantic equivalence claim for all 102 P4OMP outputs rests on 'manual execution' with no protocol. The paper does not specify the input sizes used, the number of evaluators, the comparison criterion (exact output match, tolerance, or allowed scheduling-dependent differences), or how data races and nondeterministic reductions were adjudicated. Since semantic preservation is part of the central correctness claim, this step needs a documented, reproducible protocol, and the validation logs should be included in the artifact.
[IV.A and V, Table I] All compilation outcomes come from one generation per configuration at temperature=0.2. LLM generation is stochastic, so a single run cannot establish that P4OMP 'eliminates' compilation failures or that the baseline failure count is stable. Repeated runs across random seeds, or a statistical summary, are needed to support the headline percentages. The same issue applies to the retrieval parameters: the paper does not report sensitivity of the results to the number of retrieved chunks or the retrieval threshold, so the reader cannot tell how robust the 100% figure is.
[V.B and Table II] The runtime scaling claim is based on single timing measurements without repeated runs, error bars, or a comparison against baseline-generated or hand-written OpenMP versions. The paper reports only P4OMP timings, so it does not demonstrate that the speedups are attributable to the transformation quality rather than to the chosen kernels. This is load-bearing for the 'strong runtime scaling' contribution, even though it does not directly affect the compilation claim.

minor comments (5)

[Abstract and V] The abstract says '100% compilation success on all parallelizable cases' while Table I reports raw compilation success of 102/108 (94.4%); please define the denominator explicitly in the abstract to avoid ambiguity for readers who do not immediately see the exclusion note.
[II] The related-work section surveys OMPar, OMPGPT, LASSI, PragFormer, and OMPify but provides no quantitative comparison with these systems. The novelty claim that P4OMP is the first RAG-based OpenMP generation system should either be supported by a systematic search of the literature or softened to 'to our knowledge, the first' with a clear statement of the search scope.
[III.A] The description of the tutorial corpus is thin: no corpus size, chunking strategy, embedding dimensionality, retrieval threshold, or number of retrieved chunks is reported. These are tunable parameters and should be documented for reproducibility.
[V.A] Section V.A lists example cases for each baseline failure category but does not give the complete mapping of all 20 failures. A supplementary table listing each failed case number and its diagnosed error category would make the analysis easier to verify.
[VIII] The data availability statement references an anonymous repository. Before publication, please provide a versioned, permanent identifier (for example, a DOI or an archived repository snapshot) and include the validation logs and exclusion-case documentation in that artifact.

Circularity Check

1 steps flagged · score 6.0 of 10

The headline 100% compilation-success rate is made self-definitional by excluding the six cases P4OMP failed on as 'unparallelizable'; the comparison to baseline retains independent content.

self definitional [Section V, Table I and paragraph after Table I]
"Both systems failed to parallelize 6 structurally incompatible cases due to OpenMP constraints, such as non-random-access iterators or thread-unsafe containers. When excluding these 6, P4OMP achieved 100% compilation success on the remaining 102 cases, compared to the baseline’s 80.4%."

The 'unparallelizable' category is populated by exactly the six cases on which both systems, including P4OMP, failed. The effective-success denominator is then 108 minus those failures, so P4OMP's reported 102/102 = 100% is an arithmetic consequence of the exclusion rule, not an independent measurement. The paper supplies only category labels ('non-random-access iterators or thread-unsafe constructs') with no per-case demonstration that alternative OpenMP restructuring is impossible, so the classification is posterior to the observed failures. Thus the claim '100% compilation success on all parallelizable cases' reduces by construction to '100% success on all cases not excluded for failing.' Counting the six excluded cases as failures would still leave P4OMP ahead of baseline (94.4% vs.

full rationale

Apart from the denominator-exclusion issue, the paper's evaluation is not circular. The tutorial corpus is built from external OpenMP documentation (OpenMP 5.2, LLNL, Intel, GCC, academic tutorials) and is not fitted to the 108 benchmark programs; the comparison is the same LLM with and without retrieved context, so the reported improvement in compilation success on the 102 non-excluded cases is an empirical, independently interpretable result. No fitted parameter is later renamed as a prediction, and no load-bearing claim depends on the authors' prior work: references [1], [2], and [18] are cited only as motivational examples of manual parallelization difficulty. The manual semantic validation of all 102 outputs is under-specified in the preprint, but that is a reproducibility or evidence-quality concern rather than a circularity. The one substantive circular step is the treatment of the six cases that P4OMP failed to compile: the paper uses 'unparallelizable' as a post-hoc category based on those failures, which makes the 100% success-rate headline self-definitional. Because the excluded cases are few and the baseline comparison would remain favorable even if they were counted as failures, the circularity is partial rather than total, warranting a score of 6 rather than higher.

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

The central result depends on the quality of the curated OpenMP tutorial corpus, the selection of a compilable for-loop benchmark, the author classification of six unparallelizable cases, and the assumption that compilation plus a manual output check establishes correctness. Retrieval parameters and filtering thresholds are free settings that are not reported.

free parameters (5)

temperature = 0.2
Chosen for both configurations and not swept; it affects sampling diversity and therefore compilation outcomes.
top_k retrieved tutorial chunks = not reported
The number of tutorial chunks inserted into each prompt is not reported, yet it directly controls how much OpenMP context the model receives.
tutorial chunk size and retrieval threshold = not reported
The chunking strategy for the OpenMP tutorial and the cosine-similarity threshold for retrieval are unspecified, making retrieval quality underdetermined.
Stack Overflow filter thresholds = not reported
Minimum code length and valid for-loop body checks are described qualitatively; the exact thresholds determine which 94 snippets entered the benchmark.
excluded case classification = 6 cases
The authors' judgment that six cases rely on non-random-access iterators or thread-unsafe constructs removes them from the denominator and determines the 102-case effective success rate.

assumptions (4)

domain assumption The OpenMP tutorial corpus is correct and authoritative.
Retrieved snippets are treated as trusted ground truth in Section III.A and VI.A; errors in the corpus would propagate into generated pragmas.
domain assumption Compilation success is a meaningful proxy for generation quality.
The primary success metric is g++ -fopenmp compilation in Section IV.B.4; semantically wrong but compilable code is counted as correct.
domain assumption Manual semantic validation is sufficient evidence of correctness.
The paper states all 102 outputs were manually executed and compared to serial versions in Section IV.B.5, but no test harness, oracle, or input coverage is described.
domain assumption The Stack Overflow-derived benchmark is representative of parallelizable serial code.
Ninety-four of 108 cases are filtered Stack Overflow snippets with simple for-loops in Section IV.A; this may not represent real HPC code with irregular loops or pointer-heavy structures.

how reviews work

0 comments

Cite this review

Pith. "Pith review of P4OMP: Retrieval-Augmented Prompting for OpenMP Parallelism in Serial Code." pith.science (2026). https://pith.science/paper/PNTTFRW6

@misc{pith2026250622703,
  author       = {Pith},
  title        = {Pith review of: P4OMP: Retrieval-Augmented Prompting for OpenMP Parallelism in Serial Code},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PNTTFRW6}},
  note         = {Machine review of arXiv:2506.22703}
}

read the original abstract

We present P4OMP, a retrieval-augmented framework for transforming serial C/C++ code into OpenMP-annotated parallel code using large language models (LLMs). To our knowledge, this is the first system to apply retrieval-based prompting for OpenMP pragma correctness without model fine-tuning or compiler instrumentation. P4OMP leverages Retrieval-Augmented Generation (RAG) with structured instructional knowledge from OpenMP tutorials to improve the reliability of prompt-driven code generation. By grounding generation in the retrieved context, P4OMP improves syntactic correctness compared to baseline prompting with GPT-3.5-Turbo. We evaluate P4OMP against a baseline, GPT-3.5-Turbo without retrieval, on a comprehensive benchmark of 108 real-world C++ programs drawn from Stack Overflow, PolyBench, and NAS benchmark suites. P4OMP achieves 100% compilation success on all parallelizable cases, while the baseline fails to compile in 20 out of 108 cases. Six cases that rely on non-random-access iterators or thread-unsafe constructs are excluded due to fundamental OpenMP limitations. A detailed analysis demonstrates how P4OMP consistently avoids scoping errors, syntactic misuse, and invalid directive combinations that commonly affect baseline-generated code. We further demonstrate strong runtime scaling across seven compute-intensive benchmarks on an HPC cluster. P4OMP offers a robust, modular pipeline that significantly improves the reliability and applicability of LLM-generated OpenMP code.

Figures

Figures reproduced from arXiv: 2506.22703 by the authors.

**Figure 2.** Overview of P4OMP architecture: semantic retrieval of tutorial [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Speedup trends for seven P4OMP benchmarks on Graham HPC cluster. [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

18 extracted references · 15 canonical work pages

[1]

Efficient calculation of triangle centrality in big data networks,

W. M. Abdullah, D. Awosoga, and S. Hossain, “Efficient calculation of triangle centrality in big data networks,” in 2022 IEEE High Per- formance Extreme Computing Conference (HPEC) . IEEE, 2022, pp. 1–7

work page 2022
[2]

A sparse matrix approach for covering large complex networks by cliques,

W. M. Abdullah and S. Hossain, “A sparse matrix approach for covering large complex networks by cliques,” in International Conference on Computational Science . Springer, 2022, pp. 505–517

work page 2022
[3]

https://anonymous.4open.science/r/p4omp/, 2025

work page 2025
[4]

Ompgpt: A generative pre-trained transformer model for openmp,

L. Chen, A. Bhattacharjee, N. Ahmed, N. Hasabnis, G. Oren, V . V o, and A. Jannesari, “Ompgpt: A generative pre-trained transformer model for openmp,” in European Conference on Parallel Processing . Springer, 2024, pp. 121–134

work page 2024
[5]

Ompar: Automatic paral- lelization with ai-driven source-to-source compilation,

T. Kadosh, N. Hasabnis, P. Soundararajan, V . A. V o, M. Capota, N. Ahmed, Y . Pinter, and G. Oren, “Ompar: Automatic paral- lelization with ai-driven source-to-source compilation,” arXiv preprint arXiv:2409.14771, 2024

arXiv 2024
[6]

Lassi: An llm- based automated self-correcting pipeline for translating parallel scientific codes,

M. T. Dearing, Y . Tao, X. Wu, Z. Lan, and V . Taylor, “Lassi: An llm- based automated self-correcting pipeline for translating parallel scientific codes,” in 2024 IEEE International Conference on Cluster Computing Workshops (CLUSTER Workshops). IEEE, 2024, pp. 136–143

work page 2024
[7]

Pragformer: data-driven parallel source code classification with trans- formers,

R. Harel, T. Kadosh, N. Hasabnis, T. Mattson, Y . Pinter, and G. Oren, “Pragformer: data-driven parallel source code classification with trans- formers,” International Journal of Parallel Programming , vol. 53, no. 1, pp. 1–26, 2025

work page 2025
[8]

Advising openmp parallelization via a graph-based approach with transformers,

T. Kadosh, N. Schneider, N. Hasabnis, T. Mattson, Y . Pinter, and G. Oren, “Advising openmp parallelization via a graph-based approach with transformers,” in International Workshop on OpenMP . Springer, 2023, pp. 3–17

work page 2023

Show all 18 references

[9]

Cotran: An llm-based code translator using reinforcement learning with feedback from compiler and symbolic execution,

P. Jana, P. Jha, H. Ju, G. Kishore, A. Mahajan, and V . Ganesh, “Cotran: An llm-based code translator using reinforcement learning with feedback from compiler and symbolic execution,” in ECAI 2024 . IOS Press, 2024, pp. 4011–4018

2024
[10]

Detecting data races in openmp with deep learning and large language models,

M. Alsofyani and L. Wang, “Detecting data races in openmp with deep learning and large language models,” in Workshop Proceedings of the 53rd International Conference on Parallel Processing, 2024, pp. 96–103

2024
[11]

Developing an interactive openmp programming book with large language models,

X. Yi, A. Wang, Y . Yan, and C. Liao, “Developing an interactive openmp programming book with large language models,” in International Work- shop on OpenMP . Springer, 2024, pp. 176–194

2024
[12]

An assessment of large language models for openmp-based code parallelization: a user perspective,

M. Mi ˇsi´c and M. Dodovi ´c, “An assessment of large language models for openmp-based code parallelization: a user perspective,” Journal of Big Data , vol. 11, no. 1, p. 161, 2024

2024
[13]

Gpt-driven source-to-source trans- formation for generating compilable parallel cuda code for nussinov’s algorithm,

M. Palkowski and M. Gruzewski, “Gpt-driven source-to-source trans- formation for generating compilable parallel cuda code for nussinov’s algorithm,” Electronics, vol. 13, no. 3, p. 488, 2024

2024
[14]

Llm-aided compilation for tensor accelerators,

C. Hong, S. Bhatia, A. Haan, S. K. Dong, D. Nikiforov, A. Cheung, and Y . S. Shao, “Llm-aided compilation for tensor accelerators,” in2024 IEEE LLM Aided Design Workshop (LAD) . IEEE, 2024, pp. 1–14

2024
[15]

Kernelbench: Can llms write efficient gpu kernels?

A. Ouyang, S. Guo, S. Arora, A. L. Zhang, W. Hu, C. R ´e, and A. Mirhoseini, “Kernelbench: Can llms write efficient gpu kernels?” arXiv preprint arXiv:2502.10517 , 2025

2025 arXiv
[16]

Unitcoder: Scalable iterative code synthesis with unit test guidance,

Y . Ma, Y . Shao, P. Li, D. Song, Q. Guo, L. Li, X. Qiu, and K. Chen, “Unitcoder: Scalable iterative code synthesis with unit test guidance,” arXiv preprint arXiv:2502.11460 , 2025

2025 arXiv
[17]

Oracular programming: A modu- lar foundation for building llm-enabled software,

J. Laurent and A. Platzer, “Oracular programming: A modu- lar foundation for building llm-enabled software,” arXiv preprint arXiv:2502.05310, 2025

2025
[18]

Intersection repre- sentation of big data networks and triangle counting,

W. M. Abdullah, D. Awosoga, and S. Hossain, “Intersection repre- sentation of big data networks and triangle counting,” in 2021 IEEE International Conference on Big Data (Big Data) . IEEE, 2021, pp. 5836–5838

2021

Pith tools

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

[1] [1]

Efficient calculation of triangle centrality in big data networks,

W. M. Abdullah, D. Awosoga, and S. Hossain, “Efficient calculation of triangle centrality in big data networks,” in 2022 IEEE High Per- formance Extreme Computing Conference (HPEC) . IEEE, 2022, pp. 1–7

work page 2022

[2] [2]

A sparse matrix approach for covering large complex networks by cliques,

W. M. Abdullah and S. Hossain, “A sparse matrix approach for covering large complex networks by cliques,” in International Conference on Computational Science . Springer, 2022, pp. 505–517

work page 2022

[3] [3]

https://anonymous.4open.science/r/p4omp/, 2025

work page 2025

[4] [4]

Ompgpt: A generative pre-trained transformer model for openmp,

L. Chen, A. Bhattacharjee, N. Ahmed, N. Hasabnis, G. Oren, V . V o, and A. Jannesari, “Ompgpt: A generative pre-trained transformer model for openmp,” in European Conference on Parallel Processing . Springer, 2024, pp. 121–134

work page 2024

[5] [5]

Ompar: Automatic paral- lelization with ai-driven source-to-source compilation,

T. Kadosh, N. Hasabnis, P. Soundararajan, V . A. V o, M. Capota, N. Ahmed, Y . Pinter, and G. Oren, “Ompar: Automatic paral- lelization with ai-driven source-to-source compilation,” arXiv preprint arXiv:2409.14771, 2024

arXiv 2024

[6] [6]

Lassi: An llm- based automated self-correcting pipeline for translating parallel scientific codes,

M. T. Dearing, Y . Tao, X. Wu, Z. Lan, and V . Taylor, “Lassi: An llm- based automated self-correcting pipeline for translating parallel scientific codes,” in 2024 IEEE International Conference on Cluster Computing Workshops (CLUSTER Workshops). IEEE, 2024, pp. 136–143

work page 2024

[7] [7]

Pragformer: data-driven parallel source code classification with trans- formers,

R. Harel, T. Kadosh, N. Hasabnis, T. Mattson, Y . Pinter, and G. Oren, “Pragformer: data-driven parallel source code classification with trans- formers,” International Journal of Parallel Programming , vol. 53, no. 1, pp. 1–26, 2025

work page 2025

[8] [8]

Advising openmp parallelization via a graph-based approach with transformers,

T. Kadosh, N. Schneider, N. Hasabnis, T. Mattson, Y . Pinter, and G. Oren, “Advising openmp parallelization via a graph-based approach with transformers,” in International Workshop on OpenMP . Springer, 2023, pp. 3–17

work page 2023