Add section on staying generic.

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

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index 873e2e9f52063c5ba67a086edafd184678a84051..2782eee0958bb745c322ae681d646b8234eb2155 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -121,9 +121,11 @@ 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
+required (see also parapgrah \ref{StayingGeneric}. 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
@@ -139,9 +141,26 @@ 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).
+The toughest challenge by far was to fit the features and changes required by
+Recore into code that is maintained by the LLVM project. The main problem here
+is clash of goals: The LLVM project aims for code that performs well on their
+supported architectures, while Recore aims for code that performs well (or more
+often, can compile at all) on the Montium architecture.
+
+In general, these problems mainly occur because MontiumC and in particular
+MontiumIR poses a number of constraints that are not present in other
+architectures. This means that some transformations present in LLVM will violate
+these constraints (which would result in better code on most other
+architectures) resulting in miscompiled or uncompilable code.
+
+In some cases, these extra constraints can be formulated in a generic way, such
+that the LLVM code can handle architectures with or without the constraint.
+In a lot of cases, however, the constraint is so Montium specific that changing
+LLVM to support it is not feasible. In a few cases, this meant that the backend
+was changed to support more features of the LLVM IR. In other cases, a
+Recore-specific pass was added to solve these problems. In a few more cases, the
+problems are still unresolved, effectively resulting in additional constraints
+on the MontiumC language.
 
 \subsection{Pipelined scheduling}
 I've also been involved for a bit with the instruction scheduling algorithm