QiMeng-MuPa: Mutual-Supervised Learning for Sequential-to-Parallel Code Translation
Authors: Changxin Ke
Rui Zhang
Shuo Wang
Li Ding
Guangli Li
Yuanbo Wen
Shuoming Zhang
Ruiyuan Xu
Jin Qin
Jiaming Guo
Chenxi Wang
Ling Li
Qi Guo
Yunji Chen
Venue: NeurIPS 2025 poster ()
Keywords: mutual-supervised learning
code generation
HPC code translation
Primary area: applications

Abstract: The rise of GPU-based high-performance computing (HPC) has driven the widespread adoption of parallel programming models such as CUDA. Yet, the inherent complexity of parallel programming creates a demand for the automated sequential-to-parallel approaches.
However, data scarcity poses a significant challenge for machine learning-based sequential-to-parallel code translation. Although recent back-translation methods show promise, they still fail to ensure functional equivalence in the translated code. In this paper, we propose \textbf{QiMeng-MuPa}, a novel \textbf{Mu}tual-Supervised Learning framework for Sequential-to-\textbf{Pa}rallel code translation, to address the functional equivalence issue. QiMeng-MuPa consists of two models, a Translator and a Tester. Through an iterative loop consisting of Co-verify and Co-evolve steps, the Translator and the Tester mutually generate data for each other and improve collectively. The Tester generates unit tests to verify and filter functionally equivalent translated code, thereby evolving the Translator, while the Translator generates translated code as augmented input to evolve the Tester. Experimental results demonstrate that QiMeng-MuPa significantly enhances the performance of the base models: when applied to Qwen2.5-Coder, it not only improves Pass@1 by up to 28.91\% and boosts Tester performance by 68.90\%, but also outperforms the previous state-of-the-art method CodeRosetta by 1.56 and 6.92 in BLEU and CodeBLEU scores, while achieving performance comparable to DeepSeek-R1 and GPT-4.1. Our code is available at \url{https://github.com/kcxain/mupa}.

QiMeng-MuPa: Mutual-Supervised Learning for Sequential-toPParalee Code Translation
Changxin Kel.2 Rui Zhang' Shuo Wang Li Ding? Guangli Li Yuanbo Wen Jiaming Guo Chenxi Wang' Ling L
Shuoming Zhangl.
Ruiyuan Xu Jin Qin
Qi Guo Yunji Chen 1,2+
State Key Lab Processors, Institute of Computing Technology, CAS University of Chinese Academy of Sciences Institute of Microelectronics, CAS Intelligent Software Research Center, Institute of Software, CAS
Abstract
The rise GPU-based high-performante computing (HPC) has driven the widespread adoption of parallel programming models such as CUDA. Yet, the inherent complexity of parallel programming creates demand for the automated ssquential-to-parallee approaches. However, data scarcity poses significant chal- lenge for machine learning-bast sequential-to-parallle code translation. Although recent tack-translation methods show promise, they still fail ensure functional equivalence in the translated code. In this paper, we propose QiMeng-MuPP Learning framework for Sequential-to- torParllel code
novel Mutual-Supervise translation, to address the functional equivalence issue. QiMeng- QiMeng-MuPa consists of two models, a Translator and a Tester. Through an iterative loop consisting of Co-verify and Co-evolve steps. the Translator and the Tester mutually generate data for each other and improve collectively. The Tester generates unit tests to verify filter functionally equivalent translated code, thereby evolving the Translator, while the Translator generates translated code as augmented input to evolve the Tester. Ex- perimental results demonstrate that QiMeng-MuPa significantly enhances the per- formance of the base models: when applied to Qwen2.5-Codd S-Coer, not only improves Pass @1 by up to 28.91% and boosts Tester performance by 68. 88.90% but also outper- forms the previous state-of-the-an method CodeRosetta by 1.56 and 6.92 BLEU and CodeBLEU scores, while achieving performance comparable DeepSeek-RR R1 and G. Our code is available at hhttps:///e //githu/ com/ wwxpii/mmaaiaa.a..//////
Introduction
With the rapid advancement of tigh-performance computing (HPC) on GPUs, parallel programming models like CUDA have become critical tool for implementing computationally intensive tasks. Different from the simplicity and familiarity of sequential programming languages such as C, the parallel programming paradigm CUDA is fundamentally more complex, requiring expertise in both parallel logic and hardware-specife concepts, including threads, blocks, and memory hierarchy. This complexity makes manual sequential-te -o-arllll-l translation and optimization highly challenging task. Consequently, developing automated methods for sequential-te to--arallell translation holds immense potential to accelcrate computations, reduce development effort, and fully harness the power of GPU platforms.
"Corresponding author.
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

In recent years, machine learning methods have brought tremendous advances to automated sequential- to to-parallel translation. Unfortunately, the scarcity of CUDA corpora significantly limits the CUDA
To address this issue, unsupervised back- translation method in the field of Neural Machine Translation (NMT) [Sennrich et al. [016] Edunny
programming capabilities of supervised learning methods i
et al. 2018| Artetxe et al. 2018 has been widely applied in code translation [Lachaux et al. 20200]
TehraniJamsaz et al. 2024]. J. However, the syntactically and functional correctness of code translation
unable to be ensured by straightforwardly applying back-translation methods. Thus, works like
BabelTower (Wen et al. 2022] and MIRACLE [Zhu et al. [024] use static analysis and incorporate
compiling feedback to filter syntactically correct code, but they struggle to guarantee functional equivalence between the original and translated code. Although recent Large Language Models (LLMs) have shown strong potential in general code generation, achieving functional equivalence of translated code remains important for supervised fine-tuning, especially for languages with low data availability such CUDA. In conclusion, the functional equivalence issue of paneentiilttoppralllle translation due to data scarcity remains critical but unsolved.
Unit test generation methods such as TransCoder-ST [Rozière al. 2021 bring new opportunities for generating and filtering functional equivalence data by using Evo-suite Fraser and Arcuri 2011] However, Evo-suite relies on genetic algorithm which is extremely inefficient, and requires extensive adaptation work for different programming languages. LLMs can also be used to generate unit tests for programs, offering faster speeds, better scalability, and improved readability (Li and Yuan| 2024). but unit test data for supervised une-tuning are still needed.
To address the functional equivalence issue in sequential-to-paralle translation, we propose Mutual- Supervised Learning framework, QiMeng-MuPa The key insight is to establish a closed-loop that simultaneously performs code translation and functional equivalence verification, where the two components mutually generate data to enhance their generation ability and improve their performance collectively. QiMeng-MuPa consists of two models: Translator and a Tester, both of which are language-agnostic. The Translator converts source code into target code, meanwhile the Tester generates valid unit test for the given source code. To simultaneously enhance the Translator and the Tester, the proposed framework consists of two steps: Co-verify and Co-evolve. In Co-verify step, the unit tests generated by the Tester are used to validate the functional equivalence and filter the code generated by the Translator. In the Co-evolve step, the filtered generated code are used to train both the Translator and the Tester. These two steps are performed iteratively to simultaneously enhance the Translator and the Tester, i.e. the stronger Translator generates more correct translated code the augmented input for the Tester, while the stronger Tester generates more valid unit tests to filter the translated code for training the Translator. With the improvement of both the Translator and the Tester during the iteration, data scarcity can be addressed by the Translator, and functional equivalence can be guaranteed by the Tester. Thus, filtered by unit tests, QiMeng-MuPa can achieve superior performance compared to non- non-filtered or only compile-filee filtered methods, as shown in Figure 4
We conducted extensive experiments to evaluate the proposed method. More than just evaluating BLEU and CodeBL.EU scores, which primarily reflect syntactic equivalence and have little correlation with functional correctness (see Figure 9). functional equivalence of translation. Experimental results demonstrate that QiMeng-Mul signifi- cantly enhances model performance. When applied to Qwen2.5-Coder, it improves the Translator's Pass@1 1 by up to 28.91 % and boosts the Tester's 's performance by 68. 68%90%; when applied to Llama3, it increases Pass @1 I by up to 29.44% and improves Tester performance by 59.53%. In terms of translation quality, QiMeng-MuPa outperforms the previous state-of-the-art method CodeRosetta by 1.56 BLEU and 6.92 CodeBLEU, while achieving Pass@k performance comparable to DeepSeck-RI and GPT-4.1. Morcover, training Qwen3-0.6B on our filtered and verified data enables it to match the performance of GPT and DeepSeek series. To the best of our knowledge. we are the first to develop a domain-specific LLM capable of automatic code parallelization for HPC.
Pass@1 k the metric that directly reflects the
2 Methodology
QiMeng-Mune MuPa involves two models, a Translator and a Tester, which are optimized in an iterative framework. Each iteration consists of two steps: Co-verify and Co-evolve. These two steps alternate
There are only 26k repositories on GitHub containing CUDA code, compared to 41M for C.

---

XN
Tarpel
globa)
translate
void add Tod (ine a, int sdsta)
Input: Target Code
SFT
blockidr. blockots.x:
Label: Source Code
s2 (1dx < n) data[ted] 100;
Translator
Source Cude
Target Outpets
consistent?
Verified Triplets (Source, (Source,Target, Tests)
for (int 0J 1 < nJ 1++)
Source Outputs
Execution Engine
Tester
Ispurt:
generate tests
int datalll (t. DMp_Mx Mox
1000:
Input: Target Code
SFT
Keuppez (add 100, n, dabal);
Label: Unit Tests
Zeput2:
XN
Co-Verify
Co-Evolve
The Overview of QiMeng-MuPa. The framework consists of two models: Translator and a Tester, with two steps: (1) Co-verify: the translated code from the Translator and the corresponding unit tests from the Tester are jointly verified by running on CPU/GPU. If the results of the source and target programs are inconsistent or have compilation/runiing errors, the data is discarded. (2) Co-evolve: the verified parallel (source, target, unit tests) triplets from the Co-verify step are used to fine-tune both the Translator and the Tester via mack-translation, improving their performance iteratively until convergence.
Figure 1:
until both models converge. We describe the interaction between the two models in these steps in more details below. An overview of the framework is illustrated in Figure
2.1 Translator and Tester
Let L, and IL, denote the source set and target set which consist of valid code method strings, respectively. The program & E L. can be viewed as a function. Let D(x) denote the set of all valid input of program x, i.e. æ maps input D(x) the outputs s(l). We have two models: the Translator F and the Tester g.
The Translator F performs the code translation task, taking input program L, and outputting the corresponding program y E L.. In this work. we focus on the problem translating between parallel programs (c.g., CUDA) and sequential programs (c.g., C). Ideally, the translated code y E L, should be semantic equivalent with the program & E Lg. However, according to Rice's Theorem in computability theory [Rice [953). determining whether two programs semantically equivalent is an undecidable problem. Considering that the practice, the main purpose code translation is to generate code which can achieve the equivalent function, we determine to guarantee the functional equivalence of æ and y. Let = denote the functional equivalence which means for any input E D(x). the original code x and the translated code y should output the results, i.e. x(()) v(). Then the task of code translation can be defined as:
Definition 1 (Code Translation) Given the valid code E Ly in source the goal of code translation is to learn a Translator F which can generate the functional equivalent code E Th
F T. - T4,, = F(x), s.t. I y,
L.e. Vt D(E)) = x(t).
The Tester G designed verify the functional equivalence of the translated code. Thus, given the original code Lgg the Tester should be able to generate corresponding valid unit test ((x)

---

which can evaluate the functional equivalence. Thus, the generated unit test (zr) should meet two requirements. One is the validity of the generated unit test ((x), i.c. any input t g(z) should be a valid input in D(r). The other one is that the generated unit test (ar) is capable of checking the functional equivalence, i.e. given a pair of functional equivalent codes and y, for any E (ar) as the input, the output (t) of the translated code y should be the same with the output stt) of the original code z. Then the task of unit test generation can be defined as:
Definition 2 (Unit Test Generation) Gäven a source code I E TLg and the corresponding functional equivalent target code E Lt and x = y, the goal of unit test generation is to learn Tester G to generate valid unit test 9 (x) which can show the functional equivalence of x and y
Vt E (l)), E ((x) and xxt) =y(t).
2.2 Mutual-Supervised Learning Framework
Both the Translator and the Tester suffer from lack of supervised data, rendering traditional supervised learning methods infeasible. Considering the lack of supervised data of code translation, we start from a collection of multilingual program corpora as the source set. This corpora contains large, diverse set of programs, including both sequential and parallel programs. The corpora are not aligned between the two languages, making it be easily obtainable through automatic methods (e.g.. scraping from GitHub). However, since there is no alignment between the two languages, the corpora cannot be applied for supervised learning.
Fortunately, the Translator F and the Tester G can mutually generate new data for each other based on the monolingual corpora, addressing the issue of aligning data scarcity. The Tester G is able to generate unit tests (ar) to verify the functional equivalence of the generated code F(x) from the Translator F, so that the functional equivalent code pair (F(z), .)) filtered by the Tester can be used as the supervised training data of the Translator. In turn, the Translator F is able to generate some functional equivalent code. F(x) whose unit test is the same with the original code i.c. G(x), thus, the code pair (F(x), ((x) can be used as the supervised training data of the Tester. Furthermore, it is essential to simultaneously improve both the Translator and the Tester. Optimizing only the Translator without enhancing the Tester may lead to the generation of flawed unit tests, potentially misjudging the correctly translated data. Conversely, if the Translator remains unimproved, it will inevitably produce erroneous translation code, hindering the generation of useful unit tests. In conclusion, we can establish closed-loop based on the Translator and the Tester to mutually generate high-quality data and enhance their generating ability collectively.
Based the above analysis, we propose the QiMeng-MuPa, which iteratively filters data and simultancously optimizes both the Translator and the Tester. The Translator and the Tester are initialized with general LLM which has some code generation capabilities though the capability is limited. Since the corpora is multilingual, containing both sequential and parallel programs, both the Translator and the Tester language-agnostic Namely, the Translator is able to perform C-to-CUDA and CUDA-to-C translation simultaneous, while the Tester is able to generate unit tests for both C codes and CUDA codes. The proposed framework iteratively improves both the Translator and the Tester in a closed-loop. Each iteration consists of two steps, Co-verify and Co-evolve.
Co-verify In the Co-verify step, the generated code from the Translator and the generated unit test from the Tester generates are verified collectively. In the i-th iteration, given the source code denote p(y|a; 0&) as the conditional probability distribution of the target code y generated from the Translator, meanwhile, denote p( ( [z; si;) as the conditional probability distribution of the unit tests
T= = (t1, 12, ...,,,,,, } generated from the Tester. We define x(T) = y(T) to mean Vt E T, xt) = v(t).
To collect all the functional equivalent data, we examine all the source code x E L, by evaluating it with the corresponding translated code y ~ p(y]2;; zz; 0,) and generated unit tests T ~ p[T]>; Φ:), to evaluate whether (TT) = (TT). We can only evaluating whether (TT) = y(T) based on the actual results of the program's 's execution on the OS and CPU/GPU. Once (T) = y(T), it indicates two things: 1) T C D(r), meaning all the unit tests generated by the Tester are valid. 2) The Translator's s results exhibit functional equivalence. Otherwise, (T) + y(T), we cannot determine whether the inequality is due to the translation error of the Translator or the unit test generation error of the Tester. Thus, the correctness of these two model must evaluated simultaneously. This is why the two models are referred to as Co-verify.

---

After all data in the source set has been evaluated, we can obtain the i-th high-quality supervised training data S where each item is verified triplet:
x 2. -
= y(T))
Co-evolve In the Co-evolve step, verified (source, target, unit tests) triplets from Co-verify step are extracted as the supervised training dataset which is used to fine-tune both the Translator and the Tester. In the i-th iteration, giving the i-th filtered training data S. we fine-tune both the Translator and the Tester via back-translation [Lachaux et al., 2020]. For the Translator, we take the target code y generated in the Co-verify step as input, with the original code z serving the reference, to optimize the Translator with the following cross-entropy loss function:
Ltrans (0.) = - (T.s.T)ssS
log 1og
For the Tester, we take the target code y generated by the Translator as input and the generated unit tests for the original code z as output, to optimize the Tester with the following cross-entropy loss function:
Lrest (0i) ()
P(T TTj uz oi)
By optimizing the above loss function, we can evolve the Translator and the Tester.
0 arg min ((r Øi+1
arg min Cros((0;)
Note that the source set LL initialized with a collection of multilingual program corpora including both C and CUDA programs, meanwhile the Translator and the Tester are both language-agnostic. Therefore, in each Co-verify step, the filtered training dataset S also contains both C and CUDA programs. Then, in each Co-evolve step, the Translator is trained with both C-to-CUDA and CUDA- to-C supervised data, meanwhile the Tester trained with both C to unit tests and CUDA to unit tests supervised data. Thus, the performance of the two models on their corresponding tasks in both languages will improve. After that, in the co-verify step of next iteration, the Translator will generate more functional equivalent translated code, meanwhile the Tester will generate more valid unit tests, thereby filtering out more valid and diverse triplets for S This brings the improvement both models the further iterations until convergence. While it possible train separate Translators and Testers for C and CUDA, we find that language-agnostie models perform better. The possible reason is that the amount of training data is the most important factor, combining multiple languages to train amnuagge-annoste models can achieve better results.
3 Experimental Setup
3.1 Dataset
Unpaired training set. We filter the unaligned training set in BabelTower (Wen et al. 2022] which contains 501.732 C functions and 129, 497 CUDA kernel functions. Considering these functions may cannot be executed due to calls to third-party libraries or user-defined functions, we filtered these functions through compilation, obtaining 14,687 valid C functions and 28,756 valid CUDA kernel functions our training set.
Paired test sets. The validation set and test in BabelTower [en al. 2022 consist of 364 pairs of C and CUDA functions. We use GPT-4 [OpenAl et al.) 2024 to generate unit tests for each pair, and ultimately filter out 233 pairs after compilation, each with unit tests. Our generated tests achieve an average line coverage of 99%, demonstrating their robustness in exercising the functionality of the translated programs. An analysis of the test set's coverage and difficulty is included in the appendix
5

---

Table 1: Experimental Results C-to-CUDA Translation. We evaluate the performance of framework using Llama3, Qwen2.5-Coder, and Qwen3, and compare with prior stae-of-tthe-ar work CodeRosetta as well strong seneral-purpose LLMs. Evaluation is conducted across multiple metrics: BLEU, CodeBLEU, Compile Pass (CPass), and Pass (1,5,10). (QiMeng-MuPa" denotes fine-tuning with data filtered by (wen2.5-Coder.)
Text-Similarity (%)
Functional- -iaiiiial---qivleeenee (%)
Model Name
Size
BLEU
CodeBLEU
CPass
Pass@1
Pass@5
Pass @
GPT-4o GPT-4.1
76.28
46.56
89.66
83.69
92.50
94.26
75.39
36.41
83.26
80.28
92.71
94.68
DeepSeek-V/ V3 DeepSeek-R1
79.66
45.05
91.85
85.61
94.87
96.40
671B
71.40
39.00
87.98
82.23
95.46
97.63
TransCoder
0.6B
75.43
78.06
CodeRosetta
0.8B
83.40
78.84
81.10
75.96
Qwen3
61.25
36.11
31.33
11.59
20.56
22.18
0.6B
QiMeng-MuPa'
81.56
82.01
94.42
84.44
96.15
97.33
Qwen2.5-Coder
72.07
47.79
72.10
56.24
77.73
80.90
7B
+ QiMeng-MuPa
84.96
84.98
95.71
85.15
95.73
97.00
IJlam3-Instruc
69.05
42.93
68.24
56.12
71.64
74.03
8B
+ QiMeng-Muue
86.68
86.63
92.70
85.56
93.79
94.57
Code Wrappers. To support unit test execution and obtain results for C and CUDA, we preprocess the code with types of wrappers: 1) Function Call Wrapper: Some functions modify data via pointer arguments (e.g., output matrices) instead of returning values. Using C++ templates and regex, we generate wrappers that detect parameter types and print modified arrays after execution, capturing both return values and side effects. 2) CUDA Kernel Wrapper: Since CUDA kernels require control flow logic (c.g., memory initialization, data transfer, grid and block allocation) for invocation, we use base model (the prompt is provided in Appendix G to create a wrapper for each CUDA kernel in the monolingual dataset. The wrapper replicates the kernel's interface, adds control flow logic, and invokes the actual CUDA kernel, enabling CUDA kernels to be called like C functions.
3.2 Base model & fine-tuning
We use Llama3-80 Baamaa-8B-insttee 3B-instruct GGrttafioon et al.) 2024 and Qwen2.5-Coder-77 (angg et al, 2024a the base model for the Translator, Tester, and CUDA Wrapper. For generation, when generating with the closed-source models, we use one-shot prompt. For generating with the trained models and during training,
only task-specific prompts. More details for fine-tuning in Appendix D.2 and two different prompts for both code translation and unit test generation are detailed in Appendix G
be found
3.3 Metrics
We use four key metrics (BLEU PPapineni al. 2002 CodeBLEU [Ren et al. 2020), Compile Pass (CPass) and Pass @k CCen et al.) 2021] to evaluate Code Translation task and Valid Input (VT) to evaluate Unit Test Generation Task (see Appendix D.I for details).
3.4 Baselines
The main baselines we compare to are the following approaches. TransCoder [Lachaux et al. 2020] and CodeRosetta [TehraniJamsaz et al., (224) adopt encoder-decoder Transformer models for code translation. While CodeRosetta represents the current state-of-the-arr it only reports similarity-based metrics (BLEU and Code which insufficiently capture true translation quality. Besides, we evaluate the powerful closed-source models, all major OpenAl models, including GPT-40 and GPT-4.1 and two leading open-source models: DeepSeek-RI (DeepSeek-Al et al. 2025 and DeepSeck-Vi -3 DeepSeek-AA et al. 2024). DeepSeck-RR is reasoning model, achieving state-of-the-

---

56.7
9377
2440
2411 9237
$4.00
06.22
72.24
10
40.29
BLEU
CodaBLEU
CPass
Passg1
Pasagg
Paseg810 10
Figure 2: Evaluation of Code Translation across iterations of QiMeng MuMeng-MuPa based on Qwen2.5 Coder.
E roundo ground1
rouund2
round3
arunnd
@PPT4411 DGPT-4
GPP-44
50-23
1872
30.51
7237
04-11
S4.21
(CUDA)
Figure 3: Evaluation of Unit Test Generation Using the VT metric across iterations of QiMeng- MuPa based on Qwen2.5-Coder compared with GPT-4.1, GPT-4o and GPT-4.
art performance on code generation. DeepSeek-Vi Mixture-of-Experts (MoE) model optimized for general-purpose tasks.
4
Experiments Results
4.1 Code Translation
Table D and Figure shows the results compared with existing methods. QiMeng- MuPa improves Pass @ by 28.91 % for Qwen2.5-Coder and 29.44% for Llama3. Qwen2.5-Coder enhanced with
QiMeng-MuPP surpasses current state-of-the-ar CodeRosetta by 1.56 BLEU and 6.92 C.U Regarding Compile Pass and Pass @k that better reflect true model performance, QiMeng- MMPa outperforms the strongest open-source model DeepSeek-RI by 3.33% on Pass@11 and the leading closed-source model GPT-4. by 2.32% Pass @ 10. These results demonstrate that the Translator trained with QiMeng-Minn MaPa is effective on sequential-to-paraanee current state-of-the-arr models on both similarity bbased and functional equivalence-based metrics. Figure 12 shows an example where the Translator efficiently and correctly parallelizes the two outer loops, successfully translating their complex logic. In contrast, CodeRosetta produces incorrect translation. More error analysis and examples can be found Appendix B [n We also analyze the performance of CUDA programs generated by the Translator (see Table 5). achieving maximum speedup of up to 15,259x.
code translation, and surpass the
4.2 Unit Test Generation
As shown in Figure similar with Translator, the Tester also achieves state-of-the-art VT metric in generating unit tests for both C and CUDA functions. Among the closed- source open-source LLM models, the best-performing one is GPT-4.1, but it still 25.64% and 5.72% lower than our 5wen2.5 on the VT metric for C and CUDA, respectively. We analyzed and counted the cases
7

---

Table 2: C and CUDA data filtered in each Co-verify step. Translator * means freezing the
Translator and evolving only the Tester in each iteration of the Co-evolve step. Similarly, Tester refers to evolving the Translator while freezing the Tester
Code
Iter
Iter
Iter
Iter
C
759
1114
1797
2079
QiMeng-MuPa
CUDA
2459
3947
6456
8484
Tester *
C CUDA
759
1040
1205
1133
2459
3643
3906
4676
C
7559
968
1055
1315
Translator *
CUDA
24599
2783
3340
4310
Valid Inputs (VT)
Pass
75
75
60
QiMenngMuPa
non-filter
QlMeng-MUPa
QiMeng-MUPa
compile-fiter
Tester
Translator
55
Iterations of transtirnniootion
Iterations
Iterations
Figure 4: Ablation Study, Left: Comparison of the performance of the Translator using Qwen2.5- Coder with non-filter and compile-filter back- back-translation. Middle: Translator performance on Pass @ when freezing the Tester. Right: Tester performance on the VT metric when freezing the Translator.
of invalid Compilation errors mainly involve issues such as parameter type mismatches, while runtime errors mainly include incorrect understanding parameter relationships (e.g., segmentation faults due to incorrect array lengths). As shown in Figure 6 the unit tests generated from our method have less compilation errors and runtime errors, and its success rate larger than that from closed-source or open-source models. Examples of the unit tests generated by the Tester are shown in Appendix F
unit tests, which mainly include compilation errors and runtime errors.
4.3 Results of iterations
We evaluate each iteration of the Translator and the Tester based Qwen2.5-Code 2-5dederr.. The amount of data filtered by Co-verify in each iteration is shown in Table showing that the filtered paired data for code translation and for unit test generation shown in Figure 2 and Figure 3, the performance of the Translator gradually improves across all four metries with iterations, saturation the 4th iteration. Similarly, the Tester's VT metric also gradually improves with each iteration. Particularly, Figure [ shows from iteration 0 to iteration 1, runtime errors significantly decrease, while compilation errors gradually decrease in the following three iterations. These results demonstrate the effectiveness of the QiMeng-MuPa framework. More valid and paired data of code translation and unit test generation can be filtered in the Co-verify step of each iteration, meanwhile both the Translator and the Tester can be gradually improved by the filtered data in the Co-evolve step of each iteration.
both increasing during the iteration. As
When the proposed method finish, we obtain a verified dataset of 10,563 parallel functions CUDA and along with unit tests per function, automatically constructed through our framework. As shown in Table [] We trained the Qwen3-0.61 model using this dataset and achieved translation metrics comparable those of the GPT and DeepSeek series. Moreover, its Pass@ 1 8.48% higher than that of the previous state-of tfte--o-thhe-as art method at a similar parameter scale, demonstrating the high quality of our filtered dataset.
4.4 Ablation Study
Benefits from Co-verify. To evaluate the effectiveness of Co-verify, we compared the proposed method with the performance of 1) non-filtered: the training data was not filtered and back-translated
8

---

directly, and 2) compile-filtered the training data was only filtered by checking compilation. In contrast, QiMeng- Maae filtered the data with the unit tests to check the functionally equivalence. SegureAshowe the results of each iteration. Although the two comparison methods initially benefit from a larger amount of training data and show better performance in the early stages, the functionally incorrect data which cannot be filtered eventually hampers their performance. After two iterations, these two methods converge and begin to show a gradual decline in performance, while our approach continues to improve and converges after four iterations of learning. The results demonstrate the effectiveness of our method: Co-verify enhances the quality of the filtered training data, bring more improvement of the performance.
Benefits from Co-evolve. To evaluate the mutual contribution of the Translator and the Tester to each other, we freeze one model and train the other. The comparison results in three iterations are shown in Figure 4 Compared to original results of Co-evolve, freezing the other model results in a decrease of 5.72% in Pass@1 I and 3.15% in VT for the Translator and Tester. Besides, the amount of data filtered in each iteration is shown in Table 2 showning that the filtered paired data significantly decrease when freezing the Translator models contributes to selecting more data in each iteration for training. thereby enhancing the upper bound of model learning. Both the Translator and the Tester are indispensable for QiMeng-MuPa, and train both models simultaneously during the Co-evolve step can achieve the best performance.
the Tester during the iteration. This suggests that both
5 Related Work
Source-to-Source Translation. Neural Machine Translation (NMT) has made significant strides [Bahdanau et al. [214] [Sutskever et al. 2014 Vaswani et al.] (017). but translating between program- ming languages while ensuring functional equivalence remains challenging. Traditional transcompil- ers (c.g.. C2Rus 2 rely expert-defined Abstract Syntax Trees (AST) for source-to-souree compilation. Statistical Machine Translation (SMT) methods [Nguyen et al., 2013 2015) reduce the need for expertise by learning from parallel corpora, but their dependence on large datasets limits adaptation to monolingual corpora. Recent approaches have moved towards unsupervised learning. TransCoder (Lachaux et al. 2020] and TransCoder-IR (Szafraniec al. 2022 use tack-translation to train soueence-to-sequeeee models on monolingual corpora, avoiding parallel datasets. However, they face challenges in ensuring functional equivalence between corpora, which impacts model performance. BabelToower (Wen et al., 2022 improves translation quality by filtering programs with higher parallelization during back-translation using the ParaBLEU metric, while CodeRosetta [Tehran]Jamszz et al., 2024) enhances program understanding by integrating AST Entity Recognition (AER) for scquential-to-parallle translation. To address functional equivalence, TransCoder-ST [Rozière et al. 2021 uses automatically generated unit tests to filter high-quality parallel corpora for iterative fine-tuning with Evo-suite (Fraser and Arcuri 2011]. In this paper, we propose a novel framework that combines fack-transsation with unit test models to ensure functional equivalence during training.
Unit Test Generation. Unit tests are crucial for verifying program functionality and detecting errors, but manual test writing is labor-intensive and costly, making automated generation (Kumar and Mishra 2016 Sarsa et al. [0022 key research focus. Traditional search-based methods [Harman and McMinn 2010 Fraser and Arcuri [011] ensure correctness but struggle with readability and efficiency. Recently, deep learning models, particularly LLMs, have shown promise in unit test generation. Proprietary LLMs excel (Li and Yuan 2024 Bhatia et al.. 2023 Schäfer al. 2023 Siddiq et al. [023). but comparative studies (Yang et al. [024b) show open-source LLMS with supervised fine-tuning often fall short in accuracy and coverage. TestGen-LLM [Asshahwan et al. 2024] improves accuracy with a filtration process without extra training. In this paper, we introduce a novel method for training the Tester. Unlike C++/Python, which benefit from large monolingual datasets, CUDA datasets are limited. We address this by having the Tester first generate tests for C, then using the Translator to convert to CUDA. This generated data trains the Tester for CUDA tasks, overcoming the monolingual dataset imbalance and achieving excellent results.

---

6 Conclusion
In this paper, we propose novel framework, QiMeng-MuPa, for sequential-to-paral code transla- tion. The framework addresses key challenges in the field, including the scarcity of parallel corpora and the need for funcctinal equivalence verification in translation. By integrating two mutually enhancing models, the Translator and the Tester, QiMeng-MuPa iteratively improves both translation accuracy and unit test generation quality. Experimental results demonstrate that QiMeng-Mi can substantially enhance the performance of base models. Qwen2.5- 5-Cdeer with QiMeng-Mi MMPPa outperforms sfute-of-the-an methods by 1.56 and 6.92 in BLEU and CodeBLEU, respectively, and both Qwen2.5-Coder and Llama3 achieves Pass @k performance comparable to DeepSeek-Rt and 1. Furthermore, our approach helps fill the gap CUDA dataset availability and contributes a verified dataset of 10,563 parallel functions in CUDA and C, complete with automatically generated unit tests.
Acknowledgements
This work is partially supported by the NSF of China (Grants No. 6o.62525203, U22A2028, 62302483), Strategic Priority Research Program of the Chinese Academy of Sciences (Grants No.XDB0660300, XDB0660301, XDB0660302). CAS Project for Young Scientists in Basic Research (YSBR-029) and Youth Innovation Promotion Association CAS.
References
Nadia Alshahwan, Jubin Chheda, Anastasia Finogenova, Beliz Gokkaya, Mark Harman, Inna Harper, Alexandru Marginean, Shubho Sengupta, and Eddy Wang. Automated unit test improvement using large language models meta. In SIGSOFT FSE Companion, 2024.
Mikel Artetxe, Gorka Labaka, Eneko Agirre, and Kyunghyun Cho. Unsupervised neural machine translation, 2018.
Dzmitry Bahdanau, Kyunghyun Cho, and Yoshua Bengio. Neural machine translation by jointly learning to align and translate. CoRR, abs//409.00 2014.
Shreya Bhatia, Tarushi Gandhi, Dhruv Kumar, and Pankaj Jalote. Unit test generation using generative ai : A comparative performance analysis of autogeneration tools. 2024 IEEE/ACM International Workshop on Large Language Models for Code (LLM4Code), pages 54-61, 2023.
Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, et al. Evaluating large language models trained on code, 2021.
DeepSeck-Al, Aixin Liu, Bei Feng, Bing Xue, Bingxuan Wang. Bochao Wu, Chengda Lu, Chenggang Zhao, Chengqi Deng, et al. Deepseek-v3 technical report, 2024.
Dee,Seek-AI, Daya Guo, Dejian Yang. Haowei Zhang, Junxiao Song, Ruoyu Zhang, Runxin Xu, Qihao Zhu, Shirong Ma, et al. Deepseek-rl: Incentivizing reasoning capability in Ilms via reinforcement learning, 2025. URL.htttp://arxxi haapttpss/arrxv..orr/////////// w2tt:///.w.ooaaa//....... 12948
Sergey Edunov, Myle Ott, Michael Auli, and David Grangier. Understanding back-translation scale. In Ellen Riloff. David Chiang, Julia Hockenmaier, and Jun ichi Tsujii. editors, Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing, pages 489-500. Brussels, Belgium. October-Noor November 2018. Association for Computational Linguistics. doi: 10.1855//11D118-1000
Gordon Fraser and Andrea Arcuri. Evosuite: automatic test suite generation for object-oriented software. In Association for Computing Machinery, ESEC/FS '11 page 416-419, New York, NY, USA, 2011. I. ISBN 9781450304436. doi: 10. 10.1145 00.1145/022511322255177
Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, al. The llama 3 herd of models, 2024.
Mark Harman and Phil McMinn. theoretical and empirical study of search-based testing: Local, global, and hybrid search. IEEE Transactions on Software Engineering, 36(2):226-247, 2010.
10

---

Divya Kumar and K.K. Mishra. The impacts of test automation on software's cost, quality and time market. Procedia Computer Science, 79:8-15, 2016. ISSN 1877-0509. doi: https://doi. org/10. 1016//. 201..0. Computing and Virtualization (ICCCV) 2016.
Proceedings of International Conference on Communication,
Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph E. Gonzalez, Hao Zhang, and Ion Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium Operating Systems Principles, 2023.
Marie-Anne Lachaux, Baptiste Rozière, Lowik Chanussot, and Guillaume Lample. Unsupervised translation of programming languages. ArXiv, abs/2006.03511 2020.
Ke-Shen Li and Yuan Yuan. Large language models as test case generators: Performance evaluation and enhancement. ArXiv, abs/2404.13344 2024.
Anh Tuan Nguyen, Tung Thanh Nguyen, and Tien N. Nguyen. Lexical statistical machine trans- lation for language migration. In Proceedings of the 2013 9th Joint Meeting Foundations of Software Engineering, ESEC/FSE 2013, page 651 651-65,, New York, NY, USA, 2013. Association for Computing Machinery. ISBN 978 1750322223,
doi: 10.1 (0.1145/2491111 1.2494584.
Anh Tuan Nguyen, Tung Thanh Nguyen, and Tien N. Nguyen. Divide-and phase statistical migration for source code (t). In 2015 30th IEEE/ACM International Conference on Automated Software Engineering (ASE), pages 585-596, 2015. doi: 10.1109/ASF.2215..2
approach for multi-
OpenAI, Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report, 2024.
Kishore Papineni, Salim Roukos, Todd Ward, and Wei-Jing Zhu. Bleu: method for automatic evaluation of machine translation. In Pierre Isabelle, Eugene Charniak, and Dekang Lin, editors, Proceedings of the 40th Annual Meeting of the Association for Computational Linguistics, pages 311-318, Philadelphia, Pennsylvania, USA, July 2002. Association for Computational Linguistics. doi: 10.3 10.3115/1073033.107333
Shuo Ren, Daya Guo, Shuai Lu, Long Zhou, Shujie Liu, Duyu Tang, Neel Sundaresan, Ming Zhou, Ambrosio Blanco, and Shuai Ma. Codebleu: a method for automatic evaluation code synthesis, 2020.
H. G. Rice. Classes of recursively enumerable sets and their decision problems. Transactions of the American Mathematical Society, 74(2):358-366, 1953. ISSN 00029947, 10886850.
Baptiste Rozière, J Zhang, François Charton, Mark Harman, Gabriel Synnaeve, and Guillaume Lample. Leveraging automated unit tests for unsupervised code translation. ArXiv, abs/2110.06733, 2021.
Sami Sarsa, Paul Denny, Arto Hellas, and Juho Leinonen. Automatic generation of programming exercises and code explanations using large language models. In Proceedings of the 2022 ACM Conference on International Computing Education Research Volume 1, ICER '22, page 27-43, New York, NY, USA, 2022. Association for Computing Machinery. ISBN 908199881959 450391948. doi: 10.11455/500138535543577
Max Schäfer, Sarah Nadi, Aryaz Eghbali, and Frank Tip. An empirical evaluation of using large language models for automated unit test generation. IEEE Transactions on Software Engineering, 50:85-105, 2023.
Rico Sennrich, Barry Haddow, and Alexandra Birch. Improving neural machine translation models with monolingual data. Katrin Erk and Noah A. Smith, editors, Proceedings of the 54th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Pupers), pages 86-96, Berlin, Germany, August 2016. Association for Computational Linguistics. doi: 10.18653/v 1009.
11

---

Mohammed Latif Siddiq, Joanna C. S. Santos, Ridwanul Hasan Tanvir, Noshin Ulfat, Fahmid Al Rifat, and Vinicius Carvalho Lopes. Using large language models generate junit tests: An empirical study. Proceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering, 2023.
Ilya Sutskever, Oriol Vinyals, and Quoe Le. Sequence to sequence learning with neural networks. ArXiv, abs//440.32115 2014.
Mare Szafraniec, Baptiste Rozière, Hugh Leather Francois Charton, Patrick Labatut, and Gabriel Synnaeve. Code translation with compiler representations. ArXiv, abs/2207 abs/2207.03578, 2022.
Ali TehraniJamsaz, Arijit Bhattacharjee, Le Chen, Nesreen K. Ahmed, Amir Yazdanbakhsh, and Ali Jannesari. Coderosetta: Pushing the boundaries of unsupervised code translation for parallel programming. ArXiv, abs/2410.20527, 2024.
Ashish Vaswani, Noam M. Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N. Gomez, Lukasz Kaiser, and Illia Polosukhin. Attention all you need. In Neural Information Processing Systems, 2017.
Yuanbo Wen, Qi Guo, Qiang Fu, Xiaqing Li, Jianxing Xu, Yanlin Tang, Yongwei Zhao, Xing Hu, Zidong Du, Ling Li, Chao Wang. Xuchai Zhou, and Yunji Chen. BabelTower: Learning to paralpaaallllized program translation. In Kamalika Chaudhuri, Stefanie Jegelka, Le Song, Csaba Szepesvari, Gang Niu, and Sivan Sabato, editors, Proceedings of the 39th International Conference Machine Learning, volume 162 of Proceedings of Machine Learning Research, pages 23685-23700. PMLR, 17-23 Jul 2022.
An Yang. Baosong Yang. Beichen Zhang, Binyuan Hui, et al. Qwen2.5 technical report. arXiv preprint arXiv:2412.15115, 2024a.
Lin Yang, Chen Yang, Shutao Gao, Weijing Wang, Bo Wang. Qihao Zhu, Xiao Chu, Jianyi Zhou, Guangtai Liang, Qianxiang Wang, and Junjie Chen. On the evaluation of large language models in unit test generation. 2024 39th IEEF/ACM International Conference on Automated Softwrre Engineering (ASE), pages 1607-1619, 2024b.
Yaowei Zheng, Richong Zhang, Junhao Zhang, Yanhan Ye, Zheyan Luo, Zhangchi Feng, and Yongqiang Ma. Llamafactory: Unified efficient fine-tuning of 100+ language models. In Pro- ceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), Bangkok, Thailand, 2024. Association for Computational Linguistics.
Ming Zhu, Mohimenul Karim, Ismini Lourentzou, and Daphne Yao. Semi- Semi-supervised code translation overcoming the scarcity of parallel code data. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ASE '24, page 1545-1556, New York, NY, USA, 2024. Association for Computing Machinery. ISBN 17984007124877. doi: 10.1145/3691600. 3695524.
12

---

A Analysis of Tests generated for BabelTower
A.1 Statisties of Test set
We formatted the code using clang-format and used gcov to measure the test coverage for the C code in the test set. We collected statistics on the number of lines per function, number of branches, number of for loops, as well as ceeesseee branches saanchee_xxcutedd and taken at least once. The detailed statisties are shown in the table below.
Table 3: Coverage statistics summary.
lines executed
branches executed
taken at least once (%)
lines
branches
loops
(%)
(%)
Min
4
2
1
83.33
50
33.33
Max
38
24
6
100
100
100
Avg
6.79
4.47
1.68
99.17
98.91
95.8
Moreover, only 10 instances of the iine_exxeutedd metric fall short of 100%, suggesting that cases where insufficient coverage affects pass@k evaluations are rare and have minimal impact on the results.
The table reveals significant variability in the test set's code length, ranging from a few lines to several dozen. It also includes numerous branches and for loops, making it robust benchmark for evaluating LLM translation performance.
A.2 Analysis of the Tester's Coverage During Training
To investigate whether the quality of tests generated by the Tester decreases during training, we analyzed the coverage of the training set in each round using the same method. The results are shown in Figure Since no suitable coverage analysis tool is available for CUDA, we measured the coverage of each CUDA test by applying to the corresponding translated version. As shown, the average values of multiple test quality metrics exceed 95%, and only few kernels with complex branching structures remain difficult to achieve full coverage. As the training rounds progress, both the number and complexity of tested kernels increase, which makes complete coverage more challenging. However, the average coverage remains stable. This observation indicates that functional equivalence is largely preserved and that iterative training does not lead to degradation in the quality of tests generated by the Tester.
C Code
CUDA Code
Coverage (%)
50
70
Lines Exccuted (%)
Lines Executed
Branched Executed
Branched Executed (%)
(%)
Taken At Once (%)
Iterttions
Iterations
Figure 5: Coverage statistics of training sets across rounds.
A.3 Observation on the Coverage of Compute-Intensive Code
When generating unit tests for the BabelTower dataset, we also made an interesting observation regarding coverage, as illustrated in Table Unlike the rusiness-orienter Python/Java code, the C/CUDA dataset Babel'Tower is primarily composed of computation-intente involving matrix traversal operations. These kernels tend to have few branches but are highly sensitive numerical values. Consequently, for any given input, the coverage is typically very high, with most values reaching 100%.
kernels, often
13

---

B Error Type Statistics of Tests
DeepSeel-VV3
GPT-
MuPa-r0
MuPa-r1
MuPa-r2
MuPa-33
Success
compile error runtime_ene aero
a) error statistics of tests for C
O
DeepSeek-V3
GPT-4
MuPa-r0
MuPa-11
MuPa-12
MuPa-r3
b) eroor statisties of tests for CUDA
Figure 6: Statistics of error proportions during execution.
We classify the execution errors of co-verify step into 11 types of categories, described as follows:
1. Type1:
Function Overload Resolution. This typically happens when multiple functions share the same name but differ in parameter lists, and the provided arguments do not clearly match any single overload.
2. Type2:
Insufficient Arguments. Triggered when function is called with fewer arguments than required by its definition.
3. Type3: A Argument Type Mismatch: Happens when the type of an argument passed to function does not match the type expected by the corresponding parameter in the function's definition.
4. Type4: Syntax Error: Missing Symbol: Results from the absence of essential syntax elements such as semicolons (:) or closing braces ()).
5. Type5: Undefined Identifier. Occurs when a variable, function, type, or other identifier is used without being declared defined beforehand.
6. Type6: Preprocessor Directive Error. Arises from unexpected tokens incorrect syntax within #include directives.
7. Type7: Unrecognized Token: Triggered by tokens that the compiler does not recognize, often resulting from typos, incorrect syntax, or usage of invalid characters.
8. Type8: Duplicate Declaration or Standard Library Conflict. Occurs when a variable or function declared more than within the same scope when user-defined identifier conflicts with a name in the standard library.
9. Type9: Logical Sequence, Block Index, or Shared Memory Error. Pertains to errors in the logical flow of the program, incorrect calculation of block indices in CUDA programming, or improper definition and usage of shared memory.
Type Control Flow Error: Variable Initialization Bypass. Occurs when control flow statements (like goto, break, or return) skip over the initialization of variables, leading to the use uninitialized or undefined variables.
11. Typell: CUDA Kernel Call Error. Happens when there is an attempt to configure host function (meant to run on the CPU) as a CUDA kernel (meant to run on the GPU).
14

---

Table 4: Error type statistics in the co-verification step. Statistics collected from the compilation and execution feedback of 233 parallel data samples in the test set, each with unit tests (total 1165 items). Due to the complexity of feedback, not all error types are listed.
Model
Type
Type
Type
Type
Type
Type 8
Type 10
Type 11
GPT-4
43
1
0
GPT-4o
38
35
DeepSeek-V V3
43
1
19
0
CodeRosetta
33
1
22
109
0
0
0
GiMeng-MuPa-hi
43
1
12
74
10
QiMeng-MuPa-rl
44
29
QiMeng-MuPa--1
32
1
0
2
QiMeng-MuPP-r3
43
1
0
8
0
0
C Additional Experiments on QiMeng-MuPa
C.1 Experimental Results across iterations of QiMeng-MuPa using Llama3
Bouund
Bround1
round2
round3
Boundd
6. 95.03
66-36 66.60
$1.64
Sg.7
50.05
86:693376
11.07
26.55
71.54
08.24
BLEU
CodeBLEU
CPass
Pass
Passd26
Pass$210 10
Figure 7: Evaluation of Code Translation across iterations of QiMeng- MuPa based Llama3.
rruundo
roundd
round2
Brounds
round4
@PP-4411 QGPT-4
@PT-44
130
34
81.56
11.5
00.11
19:17
40
20
(C)
(CUDA)
Figure 8: Evaluation of Unit Test Generation Using the VT metric across iterations of QiMeng-Muus
based Llama3 compared with 1PT-4.1, GPT-4o and GPT-4.
C.2 Analyzing Pearson Correlations Across Evaluation Metrics in Code Translation
We computed the pairwise correlations between BLEU, CodeBLEU, compile pass, and Pass @ 1, as shown in Figure These results highlight the limitations of using BLEU/CodeBLEU alone for code translation evaluation. While BLEU/CodeBLEU correlate with text-based similarity, they fail to capture the correctness and functionality of the generated code. The weak correlations with compile pass/Pass@ @ further indicate that BLEU is unsuitable for evaluating code translation, whereas Pass is essential.
15

---

BLEU
CodeBLEU
CPass
Passgg
1.0
BLEU
1.00
0.81
0.88
0.83
0.8
CodaBLEU
0.81
1.00
0.58
0.47
0.6
CPass
0.88
0.59
1.00
0.98
0.4
Pass@1
0.47
0.98
1.00
0.2
Figure 9: Pearson correlation coefficient of different metrics.
C.3 Evaluation of CUDA Speedup after Translation
Evaluating the speedup of translated sequential-to-par too-paralelll code is essential for assessing performance gains. However, the inputs in the BabelTower and those generated by the Tester are primarily designed to verify functional equivalence, which limits the parallelized version from fully demonstrating its advantages, such the impact of data loading overhead in CUDA. To overcome this limitation, used Claude 4-Sonnet to design templates that transform the original inputs into variable-length forms and implemented random generator populate them with valid values.
We then systematically evaluated the speedup models from different training rounds across input sizes ranging from 32 to 16,384. The results, shown in Figure I0 illustrate that later-round models achieve more stable and consistent acceleration as input size increases, indicating improved robustness and scalability in the translated CUDA programs.
round0
3500
round
3000
round2
round3
2500
Speed Up
1000
500
33x32
32d54
64x32
641r4
64x129
120564
128s 129
128k256
256s 123
2562256
216
252
$125512
10246512
103441024
2048x104
2048
2048840066
409552048
#192x1
102488
409654006
92
4996x8192
5192d1992
1684
Input Size
Figure 10: Speedup results of Tester across training rounds under different input sizes. Each curve represents different training round cound0-roundls and the Speedup is measured as the runtime ratio between the translated CUDA code and its sequential counterpart.
We also manually selected three functions from the translation results test set (shown in Figure 14 and adjusted the input matrix sizes. The results in Table 5 show that the QiMeng-MuPa framework achieved a maximum speedup of 15,259.22 after increasing the input size. Our findings also demonstrate SOTA performance on the @ metric, proving that model can translate most C
16

---

functions into equivalent CUDA functions with significant speedup, saving developers time in writing CUDA code. This underscores our work's contribution the HPC field.
Table 5: Evaluation of speedup for cooselccre,,te, gemm, and transpose using CUDA translated by QiMeng- Munn-33 (Llama3-8B),
Matrix Size
kernel
32
128
512
1024
2048
4096
8192
C (ms)
0.0022
0.0397
2.6646
11.419
85.974
506.9
2550
cross conselcree
CUDA (ms)
0.0016
0.0017
0.0029
0,0074
0.0254
0.4542
1.8162
Speed up
1.381
23.121
891.651
1525.51
3381.31
1115.81
14041
C (ms)
0.0543
3.1467
198.52
1586.4
12629
gemm
CUDA (ms)
0.0067
0.0311
0.2199
0.4332
0.8276
ASpeed up
8.011
1011
902.521
3661.97
152591
C (ms)
0.0013
0.0544
0,9922
6,5693
23,986
84.911
395.02
transpose
CUDA (ms)
0.0014
0.0014
0.0025
0.0052
0.0148
0.0467
0.1818
ASpeed
0.884
36.471
384.941
1258.91
1614.47
1817.61
2172.21
D Experimental Details
D.1 Metries
Code Translation. First, there are two text similarity- metrics: BLEU PPapineni et al. 2002
which is widely used both natural language translation and programming language translation. CodeBLEU [Ren et al. [2200 which not only considers the text-level similarity of weighed n- n-gram BLEU but also injects code syntax of abstract syntax trees and code semantics of data-flow graph. Compile Pass (CPass) which evaluates the syntactical correctness of the generated code by checking whether it can compile. We use five unit tests for each pair in test set to evaluate @ass@k (Chen et al.. 2021), metric that calculate the most important metric, as truly evaluates functional equivalence. Given the test set {ar, m contains the source code 2,, unit test T {t, { indicator function [[[]] is I for true and 0 for false. We define functional check to determine whether the translated code {y ym is correct:
rate of translated code passing all the unit tests. Pass @ is
==
Check(æ, y) (t,,),,,) (ta)))
Then, the Pass@k k metric estimates the proportion of source code that can be correctly translated at least once in i attempts:
Pass @
Exource
1
where 2 represents the total number of samples for each source code, and represents the number of samples that pass the functional check.
Unit Test Generation. To ensure the diversity and complexity of the tests generated by the model. we prompt the model to generate five unit tests each time and then run them. We use Valid Input (VT) to evaluate whether all five tests successfully run, written as:
VT Σ
A The E D(x.)l
D.2 Inference & Fine-tuning
For inference, we use vLL.M wwo al. 2023 to perform inference for all open-source models. For Llama3 and Qwen2.5-Coder, set the temperature to T 1.0 and top 1.0. For Qwen3,
17

---

adopt the non-think mode and follow the official best practices, setting the temperature to T = 0.7, top_p- 0.8, and top_k k 20.
For Fine-tuning, we adopt the same hyper-paramettrs as existing supervised fine-tuning (SFT) methods (Zheng al. 2024) for most models: learning rate of 1.0 10-5, cosine learning rate scheduler, warmup ratio of 0.1, and batch size of 32 in total. Additionally, we use the same chat template in the instruct fine-tuning phase of Llama3 or Qwen2.5.
D.3 Execution
All executions our experiments (c.g.. Co-verify and evaluation) are conducted on a CPU (Intel 19- 1-14900KF) and GPU (RTX 4090 with 128 SMs). We g++ 9.3.0 compile C programs and nvce 12.1 for CUDA programs, During execution, we set maximum timeout 60 seconds. Any program that exceeds this limit is treated runtime error.
18

---

E
Case Study on Code Translation
Source Function
void squareSarial (float *d_in, in, float rd_out, int 1!) (unsigned
{ du [i] pov(d_in[s] / [d_in[s] 2.3), 3);
QiMeng- Murea /
OpenAl-ol x
globall... roid squareKerral (float +d_in, float 'd_out,
gglobal... void squareSerial (float +d_in, float su_ int idx = blockIdx.x blockDin.x threadIdx.x; (idx X) { d_out[idx] (dx / (d_in(idx] 2.35), 3.0f);
conat unsigned int 1id threadIdx.x;
const unsigned int gid blockIdx.x blockDin.x lid;
if (gid
d_out [gid] io (d_in 2.3), 3);
QiMeng-MuPa Verify Results
OpenAl-ol Verify Results
// Isput1:
// Inputt:
// Isput2:
// Input2: float d_in3[] (2.35);
d_in3 (2.36);
float d_out3(1];
flost [_)ut3
vrapper(equareeeig d_in3, d_out3, 1); // Outpută:
xrapper
d_in3, d_out3, 1);
// Dutput2:
Source C C_Output: "Return value: vold Argunents function
Source C Dutputt "Return value: void Argunenta ([.2.3 (-1.12221e125
2.2333 -1.12222e
after function
J. 1)
J. 1)*
UUDA_Output:
"Raturn
Argunents
CIDA_Output:
value: void Argunents
after function call: ([ 2.3 12221e+23 1)
after function call: ([3. ), [ inf ], 1)"
Figure 11: Case Study 1: Translating numerical loop to CUDA. Given a source C function computing numerical expression in loop, our method correctly parallelizes the loop and preserves floating-poit point behavior across edge cases. In contrast, the OpenAI-ol translation mismanages boundary conditions and yields incorrect outputs (e.g., inf instead of the expected finite value) in verification tests.
19

---

Source C Function
sppp_cree__oeeeeeep (flore +Ieg, +Ise,
+ap, *gP, opal, unz, max)
for (int i1 " npal; i1 unz opal; i1++) {
mpm1;
npnl; 12++)
int id = 11 12 nnz;
fleat ps sp[id];
float PE gp(id;
Isg [id] +- pa pgi
[id] pe pe;
QiMeng MMuaa
CodeRosetta
_goobll.. void ceeeeeerreccccreateeeeeeoee +Igg, float +Ist, float tsp, float int upal, nnz, nnx)
-ggobal... roid seuu_crosscooreeee correlatefll eIgg, iloat +lss, float tap, fleat *gP, int npml, int anz, int nnx)
int 11 threadddxxxx + blockDin.x blockIdx.X int 12 int id threadIdk.. blockDin.y blockIdz.yi
int bblockdzz.x blockDin.x threadIdz.x; int 12 blockidz.y blackDin.y threadIdx.y; muz upnl 12 nax upm1) int id i1 float pa sp[id]; float gp[id];
12
if (i1 >= apml he 11 mnz upml 12 > npml mpal)
float pa sp(id];
float pg gp[id];
Ieg[id] +- pa [ea[id] ps ps;
Isg[id] +- ps
Iss [id] pe ps:
QiMeng-MuPa Verify Results
CodeRosetta Verify Results
// Imputi:
// Inputi: const npal1 1;
npml1 1;
const int an21 =
conat 1nt bn21 3;
const int nnx1 = 3;
const int nex1 3;
Iagt [naz] nnxi] {0}:
Iagt [nnat mnx1] {0};
float Ise1 [anzi unx1] (0);
float Issi [angi amx1] - {0);
ap1 (nnzi
(0.5, 0.7, 0.6, 0.8,
ep1 [nnzi
(0.5,
0.8, 1,
0.9, 0.3, 0.2, 0.4);
0.9, 0.3, 0.2, 0.4);
float gp1 [anzi nnx1] {1, 0.8, 0.9, 0.7, 1,
float gpl [nnzi naxi] {1, 0.8, 0.9, 0.7, 1,
0.6, 0.4, 0.3, 0.5);
0.6, 0.4, 0.3, 0.5);
vrapper(cpa_ httpcpppcccoss_coorrtteeee Iegl, Ieel, spi, sp1, npali, anz1, mnxt);
(rapper(cp__crres_cco
Iegt, Iesl, sp1, gpl,
npali, nnæ1, unx1);
// Outputl;
// Outpuć1:
Source Bource_C_Oatputz
value: after function call: 0, 0, o, 0, 0,
Argunents
Source Cate___OOtpptt after function call: (I 0, 6, 0, 0, 1, 0, D,
Arguments
0, 1, 0, 0, 0, 1, 0 0, 6, 1, 00.5, 0.7, 0.6, 0.8, 1, 0.9, 0.3, 0.2, 0.4 [1, 0.8. 0.9, 0.7, 1. 0.6. 0.4, 0.3, 0.5 3)*
o, 0 1, C0, 6, 0, 0, 1, 0, 0, 0 0.5, 0.7, 0.6, 0.8, 0.9, 0.3, 0.2, 0.4 [1, 0.8. 0.9, 0.7, 1, 0.6, 0.4. 0.3, 0.6 3,
CUDA_ OuDA_Output: function call: (I 0,
"Return value: void Argunents
CUDA_ Dutpptutpt:: after
"Return value: void Argunents (I 0.6, 0.56, 0, 0.56, o, 9, o, a 1, 0.25, 0.49, D. 0.64, 6,, 1, 0, 6, 0, 0 [ 0.5, 0.7, 0.6, 0.8, 1, 0.9, 0.3, 0.2. 0.4 1, [1, 0.8, 0.9, 0.7. 1, 0.6. 0.4,
0,
0. 1, 0, o, 1, 0, 0, 6, 0 [0.6,
0.7, 0.6, 0.8, 1, 0.9, 0.3 0.2, 0.4 1, [1,
0.8, 0.9, 0.T. 0.6. 0.4. 0.3, 0.5
0.3, 0.5 1, 3, 3)
Figure 12: Case Study 2: Boundary-sensitive loop translation. The source function applies nested loop with custom boundaries. Our translation correctly parallelizes both loops and preserves the boundary conditions. In contrast, CodeRosetta omits necessary checks, potentially leading to out-of-bound memory accesses.
20

---

Source C Function
void boxeaScale, cppceonat float +input, float soutpat, int dina, float scaleD, fleat acalel, scale2, float scale3)
for (int tid 6; tid < dins; tid++) {
output [tid 4] input[tid
scale0;
output (tid 4 + 1] input (tid 4 1] scalel;
output (tid
input((id
2]
scale2;
output (tid 4 3] input[tid 4 3]
acale3;
QiMeng Marna
CodeRosetta
gllobal... senesscalo_kerelll kernel
-gobbal.. void boxesScale, saanBclle_gu(ccoaa I +input, T
+input, float routpat, int dins, float scaleo, scalel, float acale2, fleat scale3) int tid blockIdr.x blockbin.x threadIdr. if (tid dina) return;
*output, int scale2, T scale3) {
scale0, scalel, T
blockIdx.x blockDin.x threadIdx.x; if (sid dime) input(tid scale0; output [tid 4 1] input (tid
output [tid
output [tid
input
scale0;
scalel;
output [tid x 1] input [tid 4 1]
output [tid
input(tid
scalel;
scale2;
output [tid 4 2] input[(id 2]
output [tid inpat[tid
scale2;
scale3;
output scale3;
input
QiMeng- MuPa Verify Results
CodeRosetta Verify Results
// Inputi: float input3 {,, 3, 6, 8);
// Inputi: float input3 {1, 3, 6, 7, 8);
rloat outputa[#]] wrapper imput3, output3, 1,
float outputa[s]]
wrapper (boxesssooxeccceeeeec input3, output3, 2,
3, 4);
3, 4);
Source_C_Oatppa C_Output:
roid Argunents after function call: 1,1, 2, 4, 6, J. [1 1, 1, 6, 3, 2.33833, ]. 2, 1, 4)"
Argunents after function call: ([ 1, 3, 5, 7,
C_Output:
1. [1, 1, 1, 5, 3, 2.33333, ], 2, 1, 2.
3, 4)"
CUDA Output:
"Return value: void Argunenta
CUDA_ SuDA_Gutput: "Compilation Error: identifier "T" is undefined"
function call:
J. 11, 1. 1, 1, 5, 3, 2.38833, 2 ]. 2, 1, 2,
Figure 13: Case Study Loop-based tensor scaling with type handling. The source function scales each dimension of 4-element tensor independently. Our method correctly maps the loop to CUDA kernel and preserves the correct function signature and type. In contrast, CodeRosetta produces syntactically invalid kernel with unresolved template type T, leading compilation emror.
21

---

Source
Translated CUDA
cpu, crop_cross_coom correlato(fflla Ing, Iss, float float int npnl, int nnz, int nax) {
_loobal... cuda_ www.scrrooooeetooeee corrolate(floos Ing.
float Iaa, float float int npm1, int nn2, int nax)
int 12, id;
int 11 threadIdx.x blockDim.x
float pa, PK:
blockIdx.X;
upal; i1+1) { for (:2 upml; i2 < max npal; 12+4)
upal;
threadIdz.y blockDin.y
blockIdx.y;
nnz;
noz;
[id];
(11 >4 npel && 11 nnz npm1 &8 >e npm1
Pg gp [id];;;
&t 12 nnx ngm1) {
Ing[id] pa P85
pa sp[id];
Iea [id] +- pa pa;
flaa pg gp[id];
Ieg[id] pe PS: Isa Isa [id] +
Source
Translated CUDA
void devico_gemmdduuee (doube _..restrict_. A, double __rretrric__ B, double __.retrrcct__ C, double alpha, double beta, int M, int n. int K, bool B_T
globbll_. void device geeenggennnnn (double reatrictt_
A, double restrict__.. B, double rrsttrict... C, double alpha, double beta, int B_T
A_T
H, K, A_T false) {
for (int i - 0; < K; i++) { double temp
j i+-)
int blockIdx.x blockbin.x threadIdx.x; int 1 blockIdx.y blockBin.y threadIdr.y:
for (int
K; ktt)
(j <))
double left A_T ADk + +
double temp
Ali k M];
for (int 0; K; k++)
right
BC
A_T Alk
A(i
B[k + j K];
x * M);
temp
right;
right B_T B[J K];
c(i M] alpha temp beta
temp +- left right;
cli j M);
c[i + j MJ alpha temp bata c[i
j
}
Source
Translated CUDA
void devico transpose (double (doubl
data, double
globbal__ void device tranapase data, double result, ist и, int threadIdx.yr
result, 1nt и, int N) { int
int blockIdx.y blockDin.y
for (i 0; < H; i++)
int blockIdx.x blockDin.x thresdIdx.:;
for (1
j++)
((s (j N))
result(j (j + i X] datali + M);
result(s i X] datali M);
return;
return;
Figure 14: Translation examples of three classical matrix operations. Each shows pair of source C code (left) and its corresponding translated CUDA implementation (right), including cross-correlation, general matrix multiplication (GEMM), and matrix transposition. These results produced by QiMeng-MuPa- (Llama3-8B).
22

---

Source
Translated CUDA
static void double
n, double alpha,
-.glbbal.. void simple_dgenn(in n, double alpha,
double +8, double beta,
const *A, double double beta, double +C) { blockIdx.y blockDin.y ttreadddx.y; int col = blockIdx.X blockDin.X threadIdx.X; (row && col
double +C) {
1.
for (1 = 0; 1 < ++1) {
for (j 0; <u; +t))
double prod
double prod
for Ok 0; < n; ++k) prod
for (int 0; m; +*k)
B[J k];
prod
B[col x];
}
ctj
alpha prod c(j
cicol row] alpha prod C[col rosl;
i1;
Source C
Translated CUDA
void add, bian(ffoat routput, float *biases, batch, int int size)
gllbbal.... roid add, bdas_ Cernel(floss ttr.aallllrrrallllos soutput, flost +biases, int batch, int a, int size) { (blockIdz.x blockIdx. gridDin.x) blockDin.x + threadIdx. (index size batch)
j.
for (b = b batch; ++b) {
for (1
for (j = ni ++1) +t5) {
return; int index X. size;
output [[b a i) * size + j]
biases[i];
index
int index X. m; index
int index;
outpat[(k n f) size i] biases [j];
Source CUDA
Translated
globbll.. void letriaauulUDDA(llaat +c, float +A,
void natrisMal(PU(1loa +c, float +A, float -B,
float +B, int {
int k;
for (int 1 = 0; 1 < ++1)
threadIdx.y,
threadIds.x;
++f) float aun 0.0f;
(int
float sum 0.0f;
(x 05 my +*k)
for 0; ns +*k)
+- A[row + X] B[k coll;
A(1 x] B(k fl;
}
C(rov coll
c(i
j]
Figure Some Cases of Training Set Back-tranee back-translation. This figure demonstrates the translation of various computational functions from C to CUDA using back-translation. The source C code (left) and the translated CUDA kernels (right) are shown for three different operations: matrix multiplication (top), bias addition (middle), and a simple general matrix multiplication (bottom). These cases are part the training set used to improve the performance and accuracy of the back-translation process.
23

---

Case Study on Unit Test Generation
To ensure diversity in generation, rather than always selecting the simplest test, we have the Tester generate five tests each time, separated by '/f".
Source CUDA
// hermei_fsmctonn
ggoobal__ void pow, now_ternel(int (int E, float ALPHA, float I, int INCX, float Y, int INCY)
(blockIdx.x blockIdz.y gridDim.x) blockDin.xx threadIdk.2;; 1f < N)
Y[i INCY] pou(X[s INCX], ALPHA);
// urapper__ urapper_function function void pow. _exenell invoke_ cppppke X, float ALPHA, float+ X, int INCI, float- Y, int INCY) float= d.X;
floatx d_Y; (udd 8 sizeof (fleat));
cadaMalloc (t, R aizeof (fleat));
cadaMencpy (d_x, x, X (tloat),,, cudaMen.pprfoattoobrr..))
int nunBlocks (f blockSize 1) blockSize; pou kermlollccmmml.cck. blockSize>>>>t ALPHA, d_x, d.Y, INCY); cudaMancpy(Y, d_y, aizeot (tloat), cudatenccyybavsccooottttt)) cudaFree(d_E) cadaFrea(d_)
Test
Test
Test
int 8 8;
int N 5;
int - 6;
ALPHA 2.0;
3.5;
0.5;
float X[] = {1.0, 2.0, 3.0, 4.0,
float X {10.0, 20.0, 30.0,
float X(] (-2.0, -1.0, 0.0,
5.0, 6.0, 7.0, 8.03;
40.0, 50.03;
2.0, 3.0);
IXCI 1;
int IBCX
INCI
float Y(] = {0.03;
float YD = {0.03;
float YO] (0.03;
INCY
wrapper( pou, now_kernel,_ invoell_iivvee_eee in_ N, ALPHA, Y, IECT);
wrapper( pou pov_kernel_ sevrzel_ivvoe____e opp, ALPHA, X, INCX, Y, INCY);
wrapper(
pow_ pew_kernel_
cpp, ALPHA, X, INCX, Y, INCY);
Test
Test
int N
Int 9;
float ALPHA 1.2;
float ALPHA 0.1;
float X[] {10.0, 20.0, 30.0);
float XD (1.0, 2.0, 3.0, 4.0,
int INCX 1;
5.0, 6.0, 7.0, 8.0, 9.03; INCX
Y[] (0.0);
int INCY 1;
float YD - (0.0);
wrapper(
pov_ fou_kerneel_cce cuda__iivkee ii_cpp, ALPHA, X, IRCX, Y. INCY);
vrapper( pos_kernel_cude wtt..aaiivvok_ii...p...p.
N, ALPHA, X, INCX, INCY);
Figure 16: Case Study 1: This CUDA kernel performs element-wist power computation. The generated tests vary input values and exponents to capture the kernel's sensitivity to numerical differences.
24

---

Source
vold get, before, dataaaaappp cpatcaaatccnnttttt
#boxes, const float sscores, const +labela, const *index, float +boxea_out, float sacores_out, int +labelsoot,, int dine) {
for (int tid 0; tid dims; tid+*)
(index[tid] 0)
bexen_out:[tie = [] -1;
boxes_out
beves_out(tid x 4 2] -1;
boxes_out[1lee
3] -15
(oores_ou((ti]] -1;
labele_out(tid) -1;
} else
[itea_oa[[tid = []
bozea [tidd
0];
Dexes__ot(tte
moxes_out[tie 4 2]
boxee [tid 2]:
boxes_ eexes_ou[[iid
bozee(tid
ecores_out (tid] scires(tid];
labols_out (tid] labele(tid];
Test
Test
Test
float boxesi = <0, 0, 10, 10);
fleat boxes2[] = {-1, -1, 3, 3);
float boxas3[] (1, 2, 3, 4, 6, 6, 7, 82:
float acorea1 (0.97:
fleat scores2 (0.7);
1nt labele1 {0):
int 1abels2[] (1);
fleat acores3[] {0.8, 0.7,
int indexi 0 (0);
int index2[] {0);
0.6, 0.5, 0.4, 0.3, 0.2, 0.1);
float boxes_out11 [4];
float boxes_eut2[4]:
float snorea_out11l0
flaat scares_ooe acares_out2[il out][[];
int labela3[] 10, 1, 2, 3, 4,
labele_outi
lebels_out?[1]; int dine - 1;
7);
int dins - 1;
int index3 (0, 1, 2, 4,
wrapper(
vrapper( get_before data__dat_pp, boxes2, scores2, labels2, index2, boxes, out2, scares_out2, labels_out2, dins?);
5, 6, 7h; fleat boxes_out3(8);
cet_before_anee _ep_______d boxesl, scoresi, labelsi, indext, boxes_ore outs, outl, labela_outl, dinsi);
fleat scores_out3(s];
labels_out3[e];
int dins =; vrapper(
bttbbefor___ss_dee bozes3, acores3, labels3, index3, boxes_out3, scores_out3, labels_out3, dims3);
Test
Test 5
float boxes4[] {10, 10, 20);
float boxes5[] {-10, -5, 10);
acoresá (0.97:
int labeled[] - (0):
int 1abels5[] (1):
indexd[] {0);
index5[]
float boxes_oute [oee__out4(4]
float boxes_eutS [4];
float scores_out4[1];
float scores_out:[1]}
labals_out4(1); int dina = 1; krapper(
int labels_outäät]; int dims = 1;
wrapper( jet_before_mme
get_before_umne cotor___me_ddtt_cpuuu boxerd, scores4, labale4, index4, boxes_outd, scores_out4, labols_out4, dimn);
beforr__ms_dats_cpu datadddaappp,, boxes5, scores5, labels5, index5, boxes_out5, scores_out5, labels_outt, dims);
Case Study 2: This function filters bounding boxes, scores, and labels based on the index array. The generated tests explore various input scenarios with diverse values and index patterns reveal the function's sensitivity to numerical conditions.
Figure 17:
25

---

Function 1
deubtract, matrix(doublee> for(int idx 05 1dx
c, M)
N; idx ++]
e [idx] a [idx] b[idk];
Test X
{0, // Type3: Aryusent Type Niamstch
int data2 [ {0, 0, 0); // Brror Type3: Argunent Type Nismatch
data3[] {1.0, 2.0, 3.0);
int N 3; wrapper (iaapprrddubsrract__atttt data3, data2, datal, X);
Function 2
// kernel_ [_nnction ...gobal,.. void tramsposelaiva(tnt vector inte transpased, int size) int column threadIdr.x blockbin.x blockIdv.x; int zov threadIdx.y blockDin.x blockIdx.y; if(row traneposed (rov + column size] vactor(column row size];
colume
// prapper_functioe inwealiivveeeee (pnnt vector, transpoaed, int size){
void transposellaiva
int+ d_vector;
d_transpozed;
cadaMalloe (dd _ector, size * size cizeo); ((vodd=))Rd traaspoeddd_raaspppadd,
sizeof
cudaMencpy (d_ (d_vector, vector, size size sizeof(Int) audalencyytootttoDeveee))
din3 nunBlocka((stas 15) 16, (siza 15) / 16);
din3 blockSize (16,
blockSize>> vector,, d_ t.trasppoeed size); cudaMencpy (transpozed d_transposed, cudaPrea(d (d, (d_eect));;
traneposelKaivveccccuulll
sizeof(int), cadaXMancpyloriiceeollost))
cudaFree(C (d_ (d_ttraapooed);;
Test X
int vector2[] (1, 2, 3, 4, 6, 6, 7, 83; transposad2[4]; // Rustime Brren
arapper(transpcaolaiiee ittpeeeeiivvvviiee___eeee invoke_in_cop. vector2, traneposed2, 4);
Figure 18: Some examples of invalid test cases which cause emrors during execution.
26

---

G
Prompts
G.1 CUDA Wrapper
Please help me wrap this CUDA kernel to allow user to call it like C++ function. The wrapper function should: **Keep the input and output parameters and their orders as same the as the original CUDA kernel." **
### User:
2. Call the CUDA kernel provided by user inside the wrapper function.
The generated code must be in the [CODE] and [/CODE] tags.
Here are examples for you:
CUDA Code: [CODE]
__global__ void add 100 kernel (int numElements, int* data) { int idx blockIdx.z blockDim.x threadIdx.x; if (idx < numElements: {
data[idx] 100;
}
[/CODE]
CUDA Code Wrapper: [CODE]
void add_ 10000000000 Lee__110_uuu_____a inwikiniin_pppiie numElements, int* data) {
int* d data;
CudaMalloct (void=*) bd_ numElements sizeof (int));
cudaMemcpy (d_ data, data, numElements sizeof (int),
cudaMaaccyyHossttoorric.)))
add 1_011000keeeee < 1>>> (nummlemments, data); cudaMemcpy (data, d d_data, numElements sizeof (int), cudaMMencpyDeeiieeToffosss)) cudaFree ddddd_dda;;)__
[/CODE]
Your task to write a wrapper function for the following cuda kernel function, **The generated code must be in the [CODE] and [/CODE] tags*e:
CUDA Code:
[CODE]
(cuda_codee code)
[/CODE]
CUDA Code Wrapper:
27

---

G.2 Code Translation
During training or calling the trained model, we use the Input prompt. When calling blosed-sourcs models or models not specifically trained for the task, we use Input with one-shot prompt.
You are expert in translating (obj.source) programs fobj.target programs. Given the (objesource) program by User, translate to (obj.target).. Ensure that the (obj.target) program is exactly the same the (obj.source) | program imput and output, and that the semantics of the original code are preserved. Just generate the {obj.target] program and remove any unnecessary comments. Surround the generated (obj.target) program in [(obj.target]] and (..get)).
### System Prompt:
### Input: cobjcsource_coee } ### Input with one-shot (C CUDA):
C Code:
void add add_100 (int numElements, int *data) { for (int idx 0; idx numElements; idx++)
datalidx: += 100;
}
}
CUDA Code:
.global__ void add 100 (int numElements, int *data) int idx blockIdx.x x blockDim.x threadIdx.X; x; if (idx numElements) {
[id] += 100;
}
Your task is to write a equivalent CUDA kernel function for the following C function:
Code:
jobj.source_codee _curce_ccode)
CUDA Code:
28

---

G.3 Unit Test generation
During training or calling the trained model, we use the Input prompt. When calling closed- source models or models not specifically trained for the task, we use Input with one-shot prompt.
### System Prompt: Your task is write valid inputs to rum the [obj.source) function that performs a specific calculation. You must write the comment "/input case n:" on a separate line directly above, where represents the input case number, starting from I and increasing by one for each subsequent input case.
### Input: bobjisource_code ### Input with one-shot (for C):
Code:
void add 100 (int numElementa, int *data) { for (int idx 0; idx numElements; idx++)
add_100
[id] 100;
}
}
[INPUTS]
//Input case 1: int datai {{0}}; add_100(1, datal);
//Input case 2: int data2[] {{-100}); add_100(1, data2);
//Input case 3: int data3 {(1, 2, 3}}; add_100(3, data3);
//Input case 4: int []ta4 {INT MAX 1003}; (1, data4);
//Input case 5: int data5 {{-50, 0, 50}}; add_ (3, data5);
[/NNPUTS]
Code: (obj.source_code)
H Limitations and Future Work
Although QiMeng-Mull has demonstrated promising results in sequential-to- torpaaallllll code translation. its current development still faces two main limitations: (1) The amount of available training data remains relatively small, constraining the model's ability to fully capture diverse parallel programming patterns. (2) The existing test set focuses mainly on functional correctness and contains relatively simple cases, which may not adequately reflect the model's true potential in handling complex real-world parallel tasks.
In future work, plan explore reinforcement learning techniques enable LLMS generate more efficient and high-peeformance parallel kernels, thereby further advancing the automation of HPC code generation.
29

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification:
The abstract and introduction present the experimental results and highlight the main contributions of this work.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation as long as is clear that these goals are not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations the work performed by the authors?
Answer: [Yes]
Justification:
We discuss the limitations in the Appendix
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create a separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g.. independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
the paper. The authors should use their best
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
30

---

Justification:
This work does not involve any theoretical claims requiring formal proof.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated referenced in the statement of any theorems.
The proofs can either appear the main paper or the supplemental material, but they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?
Answer: [Yes]
Justification: Our main contribution is novel algorithmic framework. We provide detailed descriptions of the dataset sources, algorithmic steps, and hyper-parameters used for both model inference and training, enabling reproducibility of our results.
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is novel architecture, describing the architecture fully might suffice, or if the contribution a specific model and empirical evaluation, it may be necessary either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of large language model), releasing of a model checkpoint, or other means that appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how reproduce that algorithm. (b) If the contribution is primarily new model architecture, the paper should describe the architecture clearly and fully.
(c) the contribution is a new model (e.g., a large language model), then there should either be way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome deseribe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should possible for other researchers to have some path to reproducing or verifying the results.
5. Open access to data and code
31

---

Does the paper provide open access to the data and code, with sufficient instruc- tions faithfully reproduce the main experimental results, as described in supplemental material?
Question:
Answer: [Yes]
Justification: An anonymous repository is included in the supplementary materials, con- taining the scripts for executing the algorithm and the intermediate data used in the final evaluation.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurIPS code and data submission guidelines (https://nips.com cc/
for more details.
While we encourage the release of code and data, we understand that this might not be possible, so "No" an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https
//nips.cc/public// wwaiiii/ggiisss/ee CCoeee//dddeSbbiiic SonpoddeummsssiooPPe.. wwriiisssiiiiiyiyioo for more details.
The authors should provide instructions on data access and preparation, including how access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results the new proposed method and baselines. If only subset of experiments reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information as possible in supplemental material (appended the paper) is recommended, but including URLs to data and code is permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification: We provide detailed descriptions of the dataset sources, algorithmic steps, and used for both model inference and training, enabling reproducibility of results in appendix and supplemental material.
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to a level of detail that is necessary appreciate the results and make sense of them.
The full details can provided either with the code, appendix, or as supplemental material.
7. Experiment statistical significance
Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Answer: [No]
Justification: The large-scale computational resources and time required for our experiments make it impractical to report error bars.
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by emor bars, confi- dence intervals, or statistical significance tests, least for the experiments that support the main claims of the paper.
32

---

The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)
The assumptions made should be given (e.g., Normally distributed errors).
It should be clear whether the error bar is the standard deviation the standard error of the mean.
is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of errors is not verified.
For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out range (e.g. negative error rates).
If error bars reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification:
We reported them in the Appendix D
Guidelines:
The answer NA means that the paper does not include experiments.
The paper should indicate the type of compute workers CPU GPU, internal cluster, or cloud provider, including relevant memory and storage.
The paper should provide the amount of compute required for each of the individual experimental runs as well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurlPS Code of Ethics
Answer: [Yes]
Justification: This work focuses on high-perffrmance code translation using publicly avail- able datasets. As such, it does not involve any ethical concerns.
Guidelines:
The answer NA means that the authors have not reviewed the NeurlPS Code of Ethics.
If the authors answer No, they should explain the special circumstances that require deviation from the Code of Ethics.
The authors should make sure to preserve anonymity (e.g.. there a special consid- eration due to laws regulations in their jurisdiction).
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [No]
Justification: We believe that this technique, by enhancing the efficiency of high-peeffrmance code development, may bring positive socictal impact. We are currently not aware of any foreseeable negative impacts.
Guidelines:
33

---

The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No. they should explain why their work has no societal impact or why the paper does not address societal impact.
Examples of negatíve societal impacts include potential malicious or unintended uses (e.g.. disinformation, generating fake profiles, surveillance), fairness considerations (c.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of MI.).
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification: This work merely introduces a training framework code translation, and do not foresee any associated risks.
Guidelines:
The answer NA means that the paper poses no such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Licenses for existing assets
Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: All data and code utilized in this study are cited with appropriate references to their original sources.
Guidelines:
The answer NA means that the paper does not use existing assets.
The authors should cite the original paper that produced the code package dataset.
The authors should state which version of the asset used and, possible, include URL.
The name of the license (c.g., CC-BY 4.0) should be included for each asset.
34

---

For scraped data from a particular source (e.g., website). the copyright and terms of service of that souree should be provided.
assets are released, the license, copyright information, and terms use in the datasets.paperssiii paperswi thcode. www.coo//aaaaa datasets package should be provided. For popular datasets,
has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
If this information is not available online, the authors are encouraged to reach out to the asset's s creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [NA]
Justification:
This paper does not release new assets.
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/mmodel as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent obtained from people whose asset is used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsourcing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given participants and screenshots, if applicable, as well as details about compensation (if any)?
Answer: [NA]
Justification:
This paper does not involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included in the main paper.
According to the NeurlPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals equivalent for research with human subjects
Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification:
This paper does involve crowdsourcing nor research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsoureing nor research with human subjects.
35

---

Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if' applicable), such as the institution conducting the review.
16. Declaration of LLM usage
Does the paper describe the usage of LLMs if is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, originality of the research, declaration is not required.
Question:
Answer: [NA]
Justification: The core method development in this research does not involve LLMS as any important, original, non-standard components.
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs as any important, original, non-standard components.
Please refer to our LLM policy hatt:p///earrrppccc/ooooeeeeeee/ /c/////oeeeeeeccc//22////.. for what should or should not be described.
36


Reviews:
[{"review_id": "YXYJv3azAO", "reviewer": "Reviewer_bgUV", "summary": "This paper proposes a Mutual-Supervised Learning (MuSL) framework for translating sequential code into parallel code. The framework consists of two components, a Translator and a Tester, that iteratively generate data for each other and improve jointly through co-evolution. Experimental results demonstrate the effectiveness of the MuSL framework in enhancing both translation accuracy and functional correctness.", "questions": "1. The paper states that \"while it is possible to train separate Translators and Testers for C and CUDA, we find that language-agnostic models perform better\", and attributes this to the larger amount of training data available when combining multiple languages. Could the authors provide empirical evidence or quantitative results to support this claim? Are there quantitative results comparing language-specific and language-agnostic models? Additionally, if more training data from other languages were included, would the performance improve further?", "limitations": "Yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 2, "significance": 3, "originality": 3, "strengths_and_weaknesses": "**Strengths**\n+ The topic of code translation, particularly from sequential to parallel code, is important to high-performance computing and software engineering.\n+ The proposed Mutual-Supervised Learning framework is language-agnostic, suggesting potential applicability beyond C and CUDA to other programming languages.\n+ The experimental evaluation demonstrates the effectiveness of the proposed approach across multiple metrics.\n\n**Weaknesses**\n- The framework is claimed to be language-agnostic, but experiments only involve C and CUDA. \n- The effectiveness of the proposed method requires further evaluation. It is unclear whether the observed performance improvements are primarily due to the proposed Mutual-Supervised Learning framework, or simply the result of training/fine-tuning the models on the dataset. As shown in Table 1, models with similar parameter sizes such as TransCoder and CodeRosetta achieve comparable results to the proposed approach, raising questions about the contribution of the framework itself versus the impact of supervised training data.\n- The evaluation settings should be described in more detail, including specifics such as the hardware configurations. Additionally, the training overhead introduced by the proposed method, especially due to the iterative co-verification and co-evolution steps, should be reported and discussed to assess its practicality and scalability.", "was_revised": true, "final_justification": "The clarification provided in the rebuttal largely addresses my concerns, and I will adjust my ratings accordingly.", "rebuttal": "Thank you for your constructive comments! We address each of the identified weaknesses and questions below.\n\n> W1. The framework is claimed to be language-agnostic, but experiments only involve C and CUDA.\n\nA1. Our work is motivated by the task of Sequential-to-Parallel Code Translation, and our method is specifically designed to address the key challenges in this setting, including three major ones.\n\n1. LLMs often lack proficiency in the source language (e.g., CUDA).\n2. Parallel data is scarce, making supervised learning difficult.\n3. The source and target languages follow different programming paradigms, increasing translation complexity.\n\nIn addition, language-agnostic means that our Translator and Tester are jointly trained for bidirectional translation, achieving better performance than training them in a single direction (see the results in A4).\n\nWhile our method can also be applied to translations between languages like Python and Java, LLMs already demonstrate strong capabilities in these languages, making alignment easier and parallel data more accessible. Therefore, we chose the more challenging C to CUDA setting. Nonetheless, we appreciate your suggestion and plan to explore C to Verilog translation in future work, where similar challenges persist.\n\n> W2. The effectiveness of the proposed method requires further evaluation. It is unclear whether the observed performance improvements are primarily due to the proposed Mutual-Supervised Learning framework, or simply the result of training/fine-tuning the models on the dataset. As shown in Table 1, models with similar parameter sizes such as TransCoder and CodeRosetta achieve comparable results to the proposed approach, raising questions about the contribution of the framework itself versus the impact of supervised training data.\n\nA2. The original training data only consists of monolingual corpora and cannot be directly used for fine-tuning. Our method introduces a framework to construct high-quality parallel data from monolingual sources, which can be used to fine-tuning. Without our framework, directly fine-tunining with the parallel data from back-translation on monolingual data yields worse performance than MuSL. As shown in our ablation study, this leds to a 5.31% perfomace drop on pass@1. Under comparable model sizes and identical data sources, our method outperforms CoderRosetta's CPass by 13% overall and achieves a 9% improvement in pass@1, which is a substantial gain.\n\n> W3. The evaluation settings should be described in more detail, including specifics such as the hardware configurations. Additionally, the training overhead introduced by the proposed method, especially due to the iterative co-verification and co-evolution steps, should be reported and discussed to assess its practicality and scalability.\n\nA3. We have already reported the evaluation hardware setup in Appendix D.3: All executions in our experiments (e.g., co-verify and evaluation) are conducted on a CPU (Intel 535 i9-14900KF) and a GPU (RTX 4090 with 128 SMs). We use g++ 9.3.0 to compile C programs and nvcc 12.1 for CUDA programs. During execution, we set a maximum timeout of 60 seconds. Any program that exceeds this limit is treated as a runtime error. Thanks to the excellent open-source projects vLLM and LLaMA-Factory, as well as our multi-threaded optimizations, our framework achieves high training efficiency. For full fine-tuning of 7B/8B models, using 8×A100-80G GPUs with DeepSpeed ZeRO-3, we complete 4 training rounds to convergence in \\~16 hours. Compared to standard fine-tuning, our framework introduces an additional Co-verify step in each round, which involves inference from both the Translator and the Tester (\\~20 minutes per round), as well as execution-based verification (\\~2 hours per round).\n\nDuring evaluation, we generate 20 samples for each of the 233 test cases and verify them in parallel, taking only \\~1 hour.\n\n> Q1. The paper states that \"while it is possible to train separate Translators and Testers for C and CUDA, we find that language-agnostic models perform better\", and attributes this to the larger amount of training data available when combining multiple languages. Could the authors provide empirical evidence or quantitative results to support this claim? Are there quantitative results comparing language-specific and language-agnostic models? Additionally, if more training data from other languages were included, would the performance improve further?\n\nA4. In early experiments, we compared training two separate models with training a single language-agnostic model and found the language-agnostic model performed better. These results are from the first training round.\n\n|   |   |   |   |   |\n|---|---|---|---|---|\n||BLEU|CodeBLEU|CPass|Pass@1|\n|sep: r1|73.33|74.91|89.96|74.66|\n|lang-agnostic: r1|79.24|78.72|91.84|76.85|\n\nWe attribute this result to three main reasons:\n\n1. C and CUDA share similar syntax and low-level semantics, enabling the model to benefit from joint training.\n2. As two distinct programming paradigms, translating in both directions helps the model learn parallel programming concepts(e.g., how to convert `for` loops into CUDA thread operations and vice versa—which are mutually reinforcing tasks.)\n3. Since the two directions are complementary, training a language-agnostic model effectively doubles the data, allowing the model to learn better representations.\n\nWe mixed 568 parallel Python/Java samples collected from UniTrans into our round2 training data and trained using the same hyper-parameters as in the paper. The results are as follows:\n\n|   |   |   |   |   |   |   |\n|---|---|---|---|---|---|---|\n||BLEU|CodeBLEU|CPass|Pass@1|Pass@5|Pass@10|\n|round2|84.24|84.32|95.28|84.08|93.48|94.61|\n|round2 w/ Java/Python|83.45|83.37|94.84|88.75|95.62|96.49|\n\nExperiments show that BLEU, CodeBLEU, and CPass scores drop, while correctness metrics like pass@k improve. This indicates that incorporating additional parallel corpora affects the model's ability to generate C/CUDA-style code, but also suggests that translation between other languages can enhance the model's C-to-CUDA translation capability."}, {"review_id": "w092NzV1Pk", "reviewer": "Reviewer_Rmzg", "summary": "This paper introduces a “Mutual-Supervised Learning” (MSL) framework for translating sequential code (C) to parallel code (CUDA) by pairing a Translator model and a Tester model. The Translator generates candidate code while the Tester produces unit tests, and they iteratively filter and improve each other via a closed-loop process.", "questions": "1. Performing equivalence testing. \n\nCan the authors explain how the equivalence testing is performed from the raw inputs? Are the function signatures aligned for the inputs? Are the outputs from program execution serialized before comparison? \n\n2. Vacuous tests discussion.\n\nCan the authors explain how the vacuous tests issue mentioned above is prevented?", "limitations": "yes", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 3, "significance": 3, "originality": 2, "strengths_and_weaknesses": "Strengths\n- Focus on missing functional correctness considerations in prior work on C - CUDA translation\n- Adding test cases to BabelTower would be a valuable contribution \n- Leveraging back-translation with test-driven \n- Extensive experiments across model backbones, metrics, and thorough ablations \n\nWeaknesses\n- Vacuous tests. The `Tester` model can cheat and only generate trivial inputs (like all zeros), which might fail to identify bugs during equivalence testing. It is unclear how the approach avoids this failure more.\n- Contamination analysis. It is unclear if the monolingual training sets are decontaminated. \n- Evaluation suite tests. The test suites only contain 5 test cases which might be less for comlpex C/Cuda functions.", "was_revised": true, "final_justification": "Reviewers have incorporated my changes. I maintain my rating.", "rebuttal": "Thank you for your positive evaluation and constructive questions. These will help clarify the methodological details in our paper. We respond to each of your points below:\n\n> W1&Q2. Vacuous tests. The `Tester` model can cheat and only generate trivial inputs (like all zeros), which might fail to identify bugs during equivalence testing. It is unclear how the approach avoids this failure more.\n\nA1. Our method avoids generating trivial inputs because it leverages LLMs such as Llama3 and Qwen2.5-Coder, which inherently possess strong capabilities for producing tests targeting compute-intensive code. However, before fine-tuning, these models struggle to handle data types and inter-data dependencies well, resulting in many errors. Therefore, during the Co-Verify stage, instead of having the tester generate one test multiple times, we generate five tests at once and extract regularized results. In the Co-Evolve stage, these five tests are collectively used as SFT outputs for training. This approach avoids training on overly simple tests repeatedly, preventing quality degradation and enhancing the model's ability to generate valid tests.\n\nWe report coverage statistics at each co-verify stage, showing that the inputs generated by our method achieve close to 100% coverage and are non-trivial, as noted in Reviewer Ekfk's Q1. Moreover, the learned tester exhibits several desirable properties, i.e. it can generate targeted test cases based on the function's semantics and data characteristics. For example:\n\n```\nint rows = 1;\nint cols = 1;\ndouble A[] = {0.0};\nreduce(rows, cols, A);\n\nint rows = 1;\nint cols = 1;\ndouble A[] = {-100.0};\nreduce(rows, cols, A);\n\nint rows = 2;\nint cols = 2;\ndouble A[] = {1.0, 2.0, 3.0, 4.0};\nreduce(rows, cols, A);\n\nint rows = 1;\nint cols = 1;\ndouble A[] = {INT_MAX - 100.0};\nreduce(rows, cols, A);\n\nint rows = 3;\nint cols = 2;\ndouble A[] = {-50.0, 0.0, 50.0, 0.0, 0.0, 100.0};\nreduce(rows, cols, A);\n```\n\nThe model not only generated matrix `A` with diverse dimensional types, but also initialized it with values such as `INT_MAX - 100.0` to test numerical stability.\n\n> W2. Contamination analysis. It is unclear if the monolingual training sets are decontaminated.\n\nA2. BabelTower performed thorough data cleaning during collection, including removing CUDA code without parallel semantics, eliminating highly duplicated samples, and filtering out code overly similar to the test set. We followed the same strategy and conducted our experiments using the same dataset as BabelTower and CodeRosetta.\n\n> W3. Evaluation suite tests. The test suites only contain 5 test cases which might be less for comlpex C/Cuda functions.\n\nA3. Using too many tests increases output length and execution time, significantly raising experimental cost; too few tests risk failing to ensure functional equivalence. We found that using 5 tests strikes a good trade-off, as shown in the coverage results in Ekfk's Q1 and the training efficiency in bgUV's Q3. Nearly all functions achieved 100% line execution coverage—this is because C/CUDA code is compute-intensive and highly sensitive to input values, so with well-designed test cases, high coverage can be achieved even with a small number of tests.\n\n> Q1. Can the authors explain how the equivalence testing is performed from the raw inputs? Are the function signatures aligned for the inputs? Are the outputs from program execution serialized before comparison?\n\nA4. Since CUDA uses C as its frontend, the two languages share identical data types. Additionally, we enforce that the parameter and return types remain exactly the same across translation, making input sharing straightforward.\n\nOur data analysis shows that most functions involve one/two dimensional arrays. We developed a rule-based C++ template system that automatically detects the parameter and return types. When arrays are present, the system flattens them and prints each element individually.\n\nWe compare the function return values along with the flattened parameters as the program's output to verify correctness. For example:\n\n```\n\"cases\": {\n\"1\": \"int mat_in1[] = {1, 2, 3, 4};\\nint mat_out1[4];\\nwrapper(gpu_matrix_transpose, mat_in1, mat_out1, 2, 2);\",\n\"2\": \"int mat_in2[] = {1, 2, 3, 4, 5, 6};\\nint mat_out2[6];\\nwrapper(gpu_matrix_transpose, mat_in2, mat_out2, 2, 3);\",\n\"3\": \"int mat_in3[] = {1, 2, 3, 4, 5, 6, 7, 8, 9};\\nint mat_out3[9];\\nwrapper(gpu_matrix_transpose, mat_in3, mat_out3, 3, 3);\",\n\"4\": \"int mat_in4[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12};\\nint mat_out4[12];\\nwrapper(gpu_matrix_transpose, mat_in4, mat_out4, 3, 4);\",\n\"5\": \"int mat_in5[] = {0, 0, 0, 0, 0, 0, 0, 0, 0};\\nint mat_out5[9];\\nwrapper(gpu_matrix_transpose, mat_in5, mat_out5, 3, 3);\"\n},\n\"outputs\": {\n\"1\": \"Return value: void\\nArguments after function call: ([ 1, 2, 3, 4 ], [ 1, 3, 2, 4 ], 2, 2)\",\n\"2\": \"Return value: void\\nArguments after function call: ([ 1, 2, 3, 4, 5, 6 ], [ 1, 4, 2, 5, 3, 6 ], 2, 3)\",\n\"3\": \"Return value: void\\nArguments after function call: ([ 1, 2, 3, 4, 5, 6, 7, 8, 9 ], [ 1, 4, 7, 2, 5, 8, 3, 6, 9 ], 3, 3)\",\n\"4\": \"Return value: void\\nArguments after function call: ([ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 ], [ 1, 5, 9, 2, 6, 10, 3, 7, 11, 4, 8, 12 ], 3, 4)\",\n\"5\": \"Return value: void\\nArguments after function call: ([ 0, 0, 0, 0, 0, 0, 0, 0, 0 ], [ 0, 0, 0, 0, 0, 0, 0, 0, 0 ], 3, 3)\"\n},\n```"}, {"review_id": "MsCktnCwQx", "reviewer": "Reviewer_Ekfk", "summary": "This paper introduces Mutual-Supervised Learning (MuSL), a framework for sequential to parallel code translation, specifically targeting C-to-CUDA generation. The core contribution is a self-supervised, iterative training loop designed to overcome the scarcity of parallel data while enforcing functional correctness. The framework employs two models: a Translator that proposes a parallel code version from a sequential source and a Tester that generates unit tests to verify the functional equivalence of the Translator's output. The process alternates between a \"Co-verify\" step, where the Tester validates the translation, and a \"Co-evolve\" step, where code pairs that pass verification are used as high-quality training data to fine-tune both the Translator and the Tester. The authors report that this mutual supervision loop significantly improves the pass rate of translations compared to strong existing baselines, addressing  the need for semantic correctness in automated code generation.", "questions": "- Can you provide a quantitative analysis of the quality and coverage (e.g., line, branch, mutation score) of the tests generated by the Tester? A positive response here, demonstrating that the Tester generates non-trivial and comprehensive tests, would significantly increase my confidence in the framework's core verification step. It might be worth stating it in the main text.\n\n- Could you please provide a more precise explanation for the Tester's improvement signal? How does fine-tuning on correct (source, translation) pairs improve its ability to generate more discerning tests for new functions, rather than simply learning to generate tests for a wider variety of functions? A convincing answer is critical for the \"co-evolution\" claim. In short, why this helps generate better tests?\n\n- Could you provide a systematic analysis of the execution-time speedup of the generated CUDA code versus the sequential C originals across your entire benchmark? A positive result showing that correctness does not come at the cost of performance would substantially strengthen the paper's practical significance.\n\n- What is the wall-clock time and total computational resource requirement for a full MuSL run on your benchmark, and how does this scale with the number of programs and iterations? This is essential for understanding the method's practicality.\n\n- Could you justify the omission of a direct comparison to TransCoder-ST? My evaluation would improve if you could demonstrate the superiority of your learned Tester against a strong, off-the-shelf test generation engine like EvoSuite used in that work.", "limitations": "While they briefly mention expanding capabilities in the appendix, they fail to discuss the most critical limitations of their work in the main paper. Constructive suggestions for improvement include:\n\n- A dedicated discussion on the fundamental gap between passing unit tests and guaranteeing true functional equivalence. The authors should be upfront that their method is a powerful heuristic for improving confidence in correctness, not a formal guarantee.\n\n- An analysis of the potential failure modes, such as the Tester generating weak or trivial tests, which could lead to a polluted training set of \"false positives.\"\n\n- A transparent discussion of the significant computational cost and scalability challenges, which are a major barrier to the practical application of this method.\n\n- The authors are not fully transparent about the limitations of their work. While they acknowledge some future directions, they do not grapple with the fundamental gap between test-passing and correctness, nor the potential for the Tester to generate trivial or non-discriminating tests.\n\n- Without a clear path to ensuring more robust correctness checks and managing the prohibitive computational cost, it is unlikely that practitioners or researchers will be able to build directly upon this method in its current form.", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths:\n\n- The work addresses a problem of high significance for the code translation community.\n\n- The core concept of an iterative, self-supervised loop for data generation and verification is theoretically elegant. \n\n- The work demonstrates good originality in its specific formulation and application.\n\n- The paper is generally well-written and organized, with the core MuSL framework being presented in an intuitive manner. The diagrams and high-level descriptions effectively convey the workflow.\n\n- The reported empirical results, showing a substantial jump in pass rates, are promising and demonstrate the potential of this direction.\n\n-  While using LLMs for code translation and test generation are individually established ideas, the proposed mutual-supervision framework, where the two models iteratively improve each other, is a novel and clever combination of existing techniques. The self-supervised approach to generating a verified, parallel dataset is a creative solution to the data scarcity problem.\n\n\nWeaknesses:\n\n\n- In my opinion, the paper's central claim of ensuring \"functional equivalence\" is not technically sound. It rests on the premise that passing a finite set of generated unit tests is a sufficient proxy for true semantic equivalence, which is undecidable by Rice's Theorem. This is the paper's most significant conceptual weakness. The framework's success is entirely contingent on the Tester's ability to generate comprehensive tests, a capability that is assumed rather than proven.\n\n- Key analyses are missing, rendering the evaluation incomplete. First, there is no systematic evaluation of the performance of the generated parallel code, a critical success metric for any parallelization task. Second, the computational cost and scalability of this iterative compile-and-run loop are not analyzed, which is a major practical concern.\n\n- The paper states the Tester is \"enhanced\" by fine-tuning on verified code pairs, but it fails to explain how observing a correct (source, parallel_code) pair provides a direct learning signal to generate better, more challenging tests for a new, unseen source program. This feedback loop is crucial to the \"co-evolution\" claim, and its underspecified nature weakens the paper's argument.\n\n- The originality is slightly diminished by the omission of a direct comparison to highly relevant prior art like TransCoder-ST, which also used a test-based verification step (albeit with a non-learned test generator). Such a comparison would have better isolated the novel contribution of the learned Tester.", "was_revised": true, "final_justification": "The original reviewer questions received attention to a certain extent. I have increased my score.", "rebuttal": "We sincerely thank you for your thorough analysis and valuable suggestions. Many of your constructive comments are helpful for improving the paper. We address each of them below and welcome further discussion.\n\n> Q1. quantitative analysis of the quality and coverage\n\nA1. We report the average coverage of tests generated by the Tester at each co-verify stage using `gcov`. Since we could not find a suitable coverage analysis tool for CUDA, we report the coverage of each CUDA test by applying it to the translated C version.\n\n|          | lines executed (%) | branched executed (%) | taken at least once (%) |\n| -------- | ------------------ | --------------------- | ----------------------- |\n| r0: C    | 98.48              | 98.57                 | 95.28                   |\n| r0: CUDA | 98.61              | 98.41                 | 95.75                   |\n| r1: C    | 97.41              | 96.29                 | 94.30                   |\n| r1: CUDA | 98.40              | 98.42                 | 95.82                   |\n| r2: C    | 97.29              | 97.40                 | 92.64                   |\n| r2: CUDA | 97.87              | 97.93                 | 94.92                   |\n| r3: C    | 96.29              | 95.27                 | 88.79                   |\n| r3: CUDA | 97.86              | 97.58                 | 94.39                   |\n\nAs shown, average values for multiple test quality metrics exceed 95%. Only a few kernels with complex branching remain hard to fully cover. As rounds progress, the number and complexity of tested kernels increase, making complete coverage harder, but average coverage remains stable. This indicates that functional equivalence is largely preserved, and iterative training does not degrade the tester's generated test quality.\n\nFor example, even for complex functions like `GCOV` with multiple branches, our Tester achieves 100% coverage.\n```\nvoid GOL(int dim, int * grid, int * newGrid) {\n    int iy, ix, id, numNeighbors;\n    int cell;\n    for (iy = 1; iy <= dim; iy++) {\n        for (ix = 1; ix <= dim; ix++) {\n            id = iy * (dim + 2) + ix;\n            numNeighbors = ...\n            cell = grid[id];\n            if (cell == 1 && numNeighbors < 2) newGrid[id] = 0;\n            else if (cell == 1 && (numNeighbors == 2 || numNeighbors == 3)) newGrid[id] = 1;\n            else if (cell == 1 && numNeighbors > 3) newGrid[id] = 0;\n            else if (cell == 0 && numNeighbors == 3) newGrid[id] = 1;\n            else newGrid[id] = cell;\n        }\n    }\n}\n```\n\n> Q2&W3. provide a more precise explanation for the Tester's improvement signal?  In short, why this helps generate better tests?\n\nA2. Our co-evolve process focuses on improving the tester's ability to generate valid tests, not directly on increasing coverage. Early experiments (e.g., results of round1) show that, since C/CUDA code is compute-intensive and often operates on entire matrices, it involves complex data flows. The model struggles to fully grasp data types and dependencies, leading to invalid tests or runtime errors. \n\nFor example, in the `transposeNaive` kernel, the length of `transposed` should match that of `vector`:\n\nbut tester generates:\n\n```\nint vector2[] = {1, 2, 3, 4, 5, 6, 7, 8}; \nint transposed2[4]; // Runtime Error \n```\n\nThis indicates that the tester's ability to recognize data dependencies is insufficient.\n\nTherefore, we designed the co-evolve framework: when the tester generates valid tests for the source, we use the target code as input to train the tester to generate valid tests for the target. Through iterative improvement, as shown in Appendix B, this approach significantly reduces runtime errors in generated tests. This indicates that the model is learning to recognize data types and dependencies, thereby enhancing its capabilities.\n\nDuring training, the tester generates 5 tests at once instead of producing 1 test sampled 5 times. This prevents repeated training on simple tests. Coverage statistics in A1 validate the effectiveness of this strategy, showing that as the model's ability to generate valid tests improves, test quality remains stable.\n\n> Q3&W2. provide a systematic analysis of the execution-time speedup of the generated CUDA code versus the sequential C originals across your entire benchmark.\n\nA3. During translator training from C to CUDA, the labels are always real CUDA kernels collected and cleaned from actual projects by BabelTower. Therefore, from an algorithmic standpoint, it is impossible for the model to sacrifice performance in order to improve accuracy. For a compute-intensive C program, as long as its loops are correctly translated into CUDA thread-level parallelism, there will inevitably be a speedup when the input matrix is sufficiently large.\n\nSince our Tester verifies functional correctness, the generated test cases usually involve small matrices, where kernel launch overhead dominates and masks any speedup. Existing tools cannot generate large-scale inputs for CUDA kernels. To overcome this, we used Claude4-Sonnet to design templates that convert fixed-length inputs into variable-length ones, and implemented a random generator to fill them with valid values. We then systematically evaluated speedup across input sizes from 2048 to 65,536.\n\nThe speedup values correspond to the average speedup observed over all successful test cases.\n\n|        | 2048  | 16384 | 65536 |\n| ------ | ----- | ----- | ----- |\n| round0 | 3.459 | 29.39 | 69.59 |\n| round1 | 3.170 | 30.83 | 84.41 |\n| round2 | 3.681 | 33.37 | 120.2 |\n| round3 | 4.189 | 29.03 | 81.98 |\n\nThese results show that our translated code consistently achieves significant speedups. The performance improves with larger vector sizes, which aligns well with practical application scenarios. Moreover, as training progresses and accuracy improves across iterations, performance remains stable without any degradation.\n\n> Q5&W4: justify the omission of a direct comparison to TransCoder-ST\n\nA4. EvoSuite is based on genetic algorithms and specifically designed for Java, which is typically used for business logic, where good tests aim to cover all control-flow branches. In contrast, C/CUDA is used for compute-intensive, numerically sensitive code involving batch operations over matrices. For compute-intensive code, good tests should involve target numerical edge cases, which is something that EvoSuite's branch coverage-based search method fails to accomplish. In contrast, in our method, the LLM-based Tester can generate tests that are aware of function semantics and data dependencies based on the inherint code generation ability of LLM, enabling more targeted and meaningful test cases, which EvoSuite often fails to capture.\n\nWe show an example demonstrating this difference.\n\nFor a CUDA kernel:\n\n```\n__global__ void Int32ToFloat32(const int32_t * input, float * output, int number) {\n    int i = blockIdx.x * blockDim.x + threadIdx.x;\n    if (i < number) {\n        output[i] = (float) input[i];\n    }\n}\n```\n\nOut Tester can generate tests like this: `int32_t input5[] = {-2147483648, 0, 2147483647};` to ensure consistent handling of boundary values before and after translation.\n\nIn contrast, after translating it to Java, EvoSuite generated the following tests:\n\n```\nint[] intArray0 = new int[2];\nfloat[] floatArray0 = new float[0];\nInt32ToFloat32.int32ToFloat32(intArray0, floatArray0, (-371));\n\nint[] intArray0 = new int[2];\nfloat[] floatArray0 = new float[5];\nInt32ToFloat32.int32ToFloat32(intArray0, floatArray0, 0);\n\nint[] intArray0 = new int[4];\nfloat[] floatArray0 = new float[3];\ntry { \n  Int32ToFloat32.int32ToFloat32(intArray0, floatArray0, 1467);\n} catch(ArrayIndexOutOfBoundsException e) {\n   verifyException(\"Int32ToFloat32\", e);\n}\n```\n\nThese tests only ensure code coverage, but the numerical values are overly simple and clearly inferior to ours.\n\nAdditionally, the example on page 18 of the paper further demonstrates that our Tester is capable of generating targeted numerical edge cases. The Tester generates the input `2.3f` based on the denominator value, which led the OpenAI-o1 model to produce `inf` after translation, successfully identifying a translation error.\n\n> W1. the paper's central claim of ensuring \"functional equivalence\" is not technically sound\n\nA5. First, for C/CUDA code, achieving high coverage is not particularly challenging, as it is typically compute-intensive rather than control-flow intensive. As shown in Q1, our evaluation of coverage demonstrates that the unit tests generated by our Tester consistently achieve high coverage. Second, while neural networks can tolerate a certain amount of data noise such as test-passing but functionally incorrect translations the high coverage of our tests ensures that such noisy samples are limited and do not negatively affect training.\n\nFurthermore, our model surpasses previous SOTA on the test set and performs on par with strong closed-source models after iterative evolution, demonstrating the effectiveness of our method. In addition, the appendix includes numerous manually analyzed cases where our model produces correct translations while others fail, further validating the method's effectiveness.\n\n> Q4. computational cost\n\nA6. We believe computational cost should be considered separately for training and inference. Since in real-world high-performance computing applications training is done only once, inference speed becomes the primary concern.\n\nOur framework involves iterative training with two models, which indeed significantly increases training cost. Our training time cost can be found in reviewer bgUV's A3.\n\nHowever, when training the Qwen3-0.6B model using our final filtered dataset, we achieve performance far exceeding CodeRosetta at comparable parameter scale. For the 0.6B model, a minimum of 2GB GPU memory is sufficient with decent output speed. Therefore, the computational cost of our proposed method is fully acceptable."}, {"review_id": "SRu04o9aSh", "reviewer": "Reviewer_YS4J", "summary": "This paper addresses the challenge of ensuring functional equivalence in sequential-to-parallel code translation, where the scarcity of parallelization data makes equivalence guarantees difficult. It proposes a Mutual-Supervised Learning (MSL) framework that enhances equivalence verification and model refinement by establishing an iterative closed loop between a Translator and a Tester.", "questions": "Overall, I don’t have any particular suggestions. I find the paper solid if somewhat conventional—its innovation is moderate, but it addresses a very practical problem. I believe it’s necessary for someone to apply a general method to a real-world domain. Therefore, I give it a weak accept.", "limitations": "yes", "rating": 4, "confidence": 4, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 2, "significance": 2, "originality": 2, "strengths_and_weaknesses": "Automatically translating existing sequential (CPU) code into efficient parallel (GPU/CUDA) code—while still guaranteeing functional equivalence in the face of scarce data—is indeed a problem worth solving. The authors’ development of a data engine combined with joint supervised fine-tuning to tackle this practical challenge represents a meaningful contribution.\n\nThe main concern is that the loop of using filtered data to train a model—and then using the improved model to further filter data—has already been explored in many previous works, so it isn’t particularly novel.", "was_revised": true, "final_justification": "I remain positive about the paper.", "rebuttal": "We sincerely thank you for your encouraging evaluation and support of our work. We are eager to clarify several aspects of its novelty and look forward to engaging in further constructive discussion!\n\n- In the C to CUDA translation domain, prior SOTA methods like BabelTower[1] and CodeRosetta[2] also employ iterative back-translation, which fundamentally assumes that training progressively reduces noise and improves data quality. However, these methods lack an intermediate filtering step, making it difficult to ensure the quality of the fine-tuning data. To address this issue, MIRACLE[3] uses static analysis and incorporates compiling feedback to filter syntactically correct code, while Transcoder-ST[4] generates unit tests using Evosuite to ensure data quality. However, the former does not truly guarantee functional equivalence, while the latter's unit test generation based on genetic algorithms has significant limitations when applied to C/CUDA. For C/CUDA, EvoSuite's branch coverage-based search method fails to generate numerical edge cases. Our method is significantly more advanced by introducing an additional tester that generates and we innovatively propose the Co-evolve Tester approach to address the issue of generating invalid tests. Our Tester is able to generate a majority of tests with 100% coverage. Moreover, since it is based on a LLM, it captures the program's semantics and produces numerical edge cases, which effectively ensures functional equivalence and thus improves training performance.\n- In instruction alignment, methods like self-alignment[5] filter data by having the model score its own outputs, but this approach still relies on uncertain generations and does not strictly ensure the quality of the generated data. Our work introduces a Tester that executes the translated code to obtain concrete feedback by running it on the CPU/GPU, ensuring the feedback comes from the real physical world.\n\n[1] BabelTower: Learning to Auto-parallelized Program Translation\n\n[2] CodeRosetta: Pushing the Boundaries of Unsupervised Code Translation for Parallel Programming\n\n[3] Semi-supervised code translation overcoming the scarcity of parallel code data\n\n[4] Leveraging Automated Unit Tests for Unsupervised Code Translation\n\n[5] Self-Alignment with Instruction Backtranslation"}]

Author rebuttal:

Meta-review: This paper proposes MuSL, a mutually supervised Translator–Tester loop for sequential to parallel code translation that generates and verifies high‑coverage test cases, yielding substantial gains. Test quality, coverage, efficiency, and scalability concerns were addressed convincingly. Reviewers converged to positive scores. The AC recommends Acceptance and the final decision.
Decision: Accept (poster)