Clarify reasons for not including loop unrolling.

[matthijs/projects/internship.git] / Report / Main / Problems / Challenges.tex

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index c70c087236bc9e3fe1bae02ba1ef6e54b91d5e77..b5d5f8e7aac725f05c35b4c31a779577d336c3cc 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -176,8 +176,10 @@ written, but I can't really tell what's needed until I know how the code works,
 which I can't effectively learn without actively working with it, etc.) I
 started out with adapting the loop unrolling pass in LLVM to be better suited to
 the Montium architecture. Eventually, this code didn't turn out to be
-immediately useful (it's still not included currently), but it proved very
-insightful as to how the LLVM framework is built and what its possibilities are.
+immediately useful because deciding when to unroll a loop and when not to turned
+out rather hard (it's still not included currently). Working with this pass did
+prove very insightful, however, as to how the LLVM framework is built and what its
+possibilities are.
 
 Additionally, during my working with the code in this internship I also produced
 a number of patches for LLVM, containing bugfixes, some cleanup and
@@ -274,8 +276,8 @@ has flexibility that the compiler will never use, it's better to save
 area and complexity by making the hardware less flexible. Exactly for this
 reason, it is important to develop hardware and supporting software in parallel,
 instead of using the hardware first, software later approach used with the
-initial Montium (TODO: Is this true?). This allows for a much better balanced
-and usable design, without any unused extras.
+initial Montium. This allows for a much better balanced and usable design,
+without any unused extras.
 
 \subsubsection{Inner loop pipelining}
 When trying to improve runtime performance, the main focus is on