Add Familiarizing with LLVM section.

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index 2787650340c41006f9c6d577a4002947e919a2ea..873e2e9f52063c5ba67a086edafd184678a84051 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -87,8 +87,48 @@ being succesfully implemented. This is conforming to the incremental development
 of MontiumC that was envisioned at the outset of its development.
 
 \subsection{Familiarizing with LLVM}
-This section says something about integrating in the LLVM community as well as
-getting acquainted with the code.
+Since during my internship I have been working mainly with LLVM (code), one of
+the first challenges was to get myself familiar with LLVM. There are two main
+aspects to this: Getting to know my way around the LLVM codebase and getting to
+know the LLVM community.
+
+Since LLVM has a pretty large amount of documentation, I spent most of my first
+weeks with reading tutorials and documents. Since there was already a (very
+preliminary) version of the clang-based frontend, I also had some code to play
+with.
+
+During this period, it was not completely clear what the frontend should
+be doing and what transformations should be written. To prevent circular
+dependencies in my tasks (I can't write any code before I know what needs to be
+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.
+
+Additionally, during my working with the code in this stage I also produced a
+number of patches for LLVM, containing bugfixes, some cleanup and documentation
+improvements. Since the best way to integrate with any open source project seems
+to be contributing code, I was giving commit access to the LLVM tree not long
+thereafter. This access has proved very useful during the rest of the
+internship, since it was now a a lot easier to make (simple) changes to the LLVM
+framework to better suit the needs of Recore.
+
+A major challenge during my internship was to find the balance between doing
+work specifically for Recore, and doing work that is useful for LLVM in general.
+Any tasks that are required by the Montium frontend and the LLVM changes they
+directly need are obvious. However, usually when making changes to the main LLVM
+code, just changing enough for Recore is not engough for LLVM. Since the LLVM
+code must work on any program, not just MontiumC programs, extra changes are
+required. This is also an issue of building up credit within the LLVM community:
+The more you contribute to LLVM, the more influence you have when things need
+changing. Lastly, this is also a matter of efficiency: If I have been working
+with a particular piece of code intensively, it is more efficient for me to fix
+a bug in that code than most others, even though the particular bug does not
+interfere with the MontiumC frontend. In the end, I think I managed to find a
+decent balance, though it might have been tipped slighly in favour of the LLVM
+project.
 
 \subsection{Coding}
 This section says something about the challenges encountered while actually
@@ -98,6 +138,7 @@ writing code, if I can think of enough things to say here.
 This section says something about working with colleagues in various ways.
 
 \subsection{Staying generic}
+\label{StayingGeneric}
 This section says something about the challenge of writing generic code:
 (changes to) transformations that are useful for both LLVM (ie on regular
 architectures) as well as for Recore (on the Montium).