Add section on staying generic.
authorMatthijs Kooijman <kooijman@eris.recoresystems.com>
Mon, 21 Jul 2008 16:15:02 +0000 (18:15 +0200)
committerMatthijs Kooijman <kooijman@eris.recoresystems.com>
Mon, 21 Jul 2008 16:15:02 +0000 (18:15 +0200)
Report/Main/Problems/Challenges.tex

index 2d85cf6ee41eb76f62b7211a68553ed98563c14c..2782eee0958bb745c322ae681d646b8234eb2155 100644 (file)
@@ -141,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