summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJohn Wickerson <j.wickerson@imperial.ac.uk>2020-09-14 22:07:02 +0000
committeroverleaf <overleaf@localhost>2020-09-14 22:09:06 +0000
commite556f7494c4539ac411be5fbdd7237f832f1eb95 (patch)
tree923f192fab9137d6bf7a2a17937b8276511e7d25
parentbd844501c75fa175c563f6183809416d48e76fc0 (diff)
downloadfccm21_esrhls-e556f7494c4539ac411be5fbdd7237f832f1eb95.tar.gz
fccm21_esrhls-e556f7494c4539ac411be5fbdd7237f832f1eb95.zip
Update on Overleaf.
-rw-r--r--conclusion.tex4
-rw-r--r--conference.bib18
2 files changed, 20 insertions, 2 deletions
diff --git a/conclusion.tex b/conclusion.tex
index cd052bb..bad70b9 100644
--- a/conclusion.tex
+++ b/conclusion.tex
@@ -1,11 +1,11 @@
\section{Conclusion}
We have shown how existing fuzzing tools can be modified so that their outputs are compatible with HLS tools. We have used this testing framework to run 10,000 test cases \JW{check numbers} through three different HLS tools. In total, we found at least 6 individual and unique bugs in all the tools, which have been reduced, analysed, and reported to the tool vendors. These bugs include crashes as well as instances of generated designs not behaving in the same way as the original code.
-One can always question how much bugs found by fuzzers really \emph{matter}, given that they are usually found by combining language features in ways that are vanishingly unlikely to happen `in the wild'. This question is especially pertinent for our particular context of HLS tools, which are well-known to have restrictions on the language features that they handle. Nevertheless, we would argue that any errors in the HLS tool are worth identifying because they have the potential to cause problems, either now or in the future. And when HLS tools \emph{do} go wrong (or indeed any sort of compiler for that matter), it is particularly infuriating for end-users because it is so difficult to identify whether the problem
+One can always question how much bugs found by fuzzers really \emph{matter}, given that they are usually found by combining language features in ways that are vanishingly unlikely to happen `in the wild'~\cite{marcozzi+19}. This question is especially pertinent for our particular context of HLS tools, which are well-known to have restrictions on the language features that they handle. Nevertheless, we would argue that any errors in the HLS tool are worth identifying because they have the potential to cause problems, either now or in the future. And when HLS tools \emph{do} go wrong (or indeed any sort of compiler for that matter), it is particularly infuriating for end-users because it is so difficult to identify whether the fault lies with the tool or with the program it has been given to compile.
Further work could be done on supporting more HLS tools, especially ones that claim to prove that their output is correct before terminating. This could give an indication on how effective these proofs are, and how often they are actually able to complete their equivalence proofs during compilation in a feasible time scale.
-As HLS is becoming increasingly relied upon, it is important to make sure that HLS tools are also reliable. We hope that this work further motivates the design of correct HLS tools, either by validating that the output is correct or by proving the HLS tool correct.
+As HLS is becoming increasingly relied upon, it is important to make sure that HLS tools are also reliable. We hope that this work further motivates the need for rigorous engineering of HLS tools, either by validating that each output the tool produces is correct or by proving the HLS tool itself correct once and for all.
%%% Local Variables:
%%% mode: latex
diff --git a/conference.bib b/conference.bib
index 7a6f32a..c8d683e 100644
--- a/conference.bib
+++ b/conference.bib
@@ -198,4 +198,22 @@ with {LegUp} High-Level Synthesis},
url = {https://doi.org/10.1109/ICVD.2003.1183177},
ISSN = {1063-9667},
month = {Jan},
+}
+
+@article{marcozzi+19,
+ author = {Micha{\"{e}}l Marcozzi and
+ Qiyi Tang and
+ Alastair F. Donaldson and
+ Cristian Cadar},
+ title = {Compiler fuzzing: how much does it matter?},
+ journal = {Proc. {ACM} Program. Lang.},
+ volume = {3},
+ number = {{OOPSLA}},
+ pages = {155:1--155:29},
+ year = {2019},
+ url = {https://doi.org/10.1145/3360581},
+ doi = {10.1145/3360581},
+ timestamp = {Thu, 16 Apr 2020 13:51:46 +0200},
+ biburl = {https://dblp.org/rec/journals/pacmpl/MarcozziTDC19.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
} \ No newline at end of file