Update on Overleaf.

1 files changed, 3 insertions, 3 deletions

diff --git a/method.tex b/method.tex
index b9356ec..701a3e3 100644
--- a/method.tex
+++ b/method.tex
@@ -31,7 +31,7 @@ This section describes how we conducted our testing campaign, the overall flow o
 For our testing campaign, we require a random program generator that produces C programs that are both semantically valid and feature-diverse; Csmith~\cite{yang11_findin_under_bugs_c_compil} meets both these criteria.
 %Csmith is randomised code generator of C programs for compiler testing, that has found more than 400 bugs in software compilers. 
 %Csmith provides several properties to ensure generation of valid C programs.
-Csmith is designed to ensure that all the programs it generates are syntactically valid (i.e. there are no syntax errors), semantically valid (for instance: all variable are defined before use), and free from undefined behaviour (undefined behaviour indicates a programmer error, which means that the compiler is free to produce any output it likes). Csmith programs are also deterministic, which means that their output is fixed at compile-time; this property is valuable for compiler testing because it means that if two different compilers produce programs that produce different results, we can deduce that one of the compilers must be wrong.
+Csmith is designed to ensure that all the programs it generates are syntactically valid (i.e. there are no syntax errors), semantically valid (for instance: all variable are defined before use), and free from undefined behaviour (undefined behaviour indicates a programmer error, which means that the compiler is free to produce any output it likes, which renders the program useless as a test-case). Csmith programs are also deterministic, which means that their output is fixed at compile-time; this property is valuable for compiler testing because it means that if two different compilers produce programs that produce different results, we can deduce that one of the compilers must be wrong.
 %Validity is critical for us since these random programs are treated as our ground truth in our testing setup, as shown in Figure~\ref{fig:method:toolflow}.
 
 Additionally, Csmith allows users control over how it generates programs.
@@ -195,11 +195,11 @@ As the programs generated by Csmith can be fairly large, we must systematically
 Reduction is performed by iteratively removing some part of the original program and then providing the reduced program to the HLS tool for re-synthesis and co-simulation. 
 The goal is to find the smallest program that still triggers the bug. 
 We apply two consecutive methods of reduction in this work. 
-We first perform a custom reduction in which we iteratively remove the HLS directives that we added before synthesis of the C program.
+The first step is to reduce the labels and pragmas that were added afterwards to make sure that these do not affect the behaviour of the program.  These are reduced iteratively until there are no more declarations left or the bug does not get triggered anymore.
 % \NR{We can add one or two more sentences summarising how we reduce the programs. Zewei is probably the best person to add these sentences.}\YH{Added some more lines, we can ask Zewei if she is OK with that.}
 %Although, our custom reduction gives us the freedom and control of how to reduce buggy programs, it is arduous and requires a lot of manual effort.
 We then use the \creduce{} tool~\cite{creduce} to automatically reduce the remaining C program.
-\creduce{} is effective because it reduces the input while preserving semantic validity and avoiding undefined behaviour.
+\creduce{} is an existing reducer for C and C++ and runs the reduction steps in parallel to converge as quickly as possible.  It is effective because it reduces the input while preserving semantic validity and avoiding undefined behaviour.
 It has various reduction strategies, such as delta debugging passes and function inlining, that help it converge rapidly to a test-case that is small enough to understand and step through.
 
 However, the downside of using \creduce{} with HLS tools is that we are not in control of which lines and features are prioritised for removal.