Add examples of various problems mentioned.
authorMatthijs Kooijman <kooijman@eris.recoresystems.com>
Mon, 15 Sep 2008 10:18:30 +0000 (12:18 +0200)
committerMatthijs Kooijman <kooijman@eris.recoresystems.com>
Mon, 15 Sep 2008 10:18:30 +0000 (12:18 +0200)
Report/Main/Problems/Challenges.tex

index 15cf290a487187cc5e3e2c96d703bc57d12467ad..d5bc0145919f7f1d4f3de0b8a2159587d8259f7c 100644 (file)
@@ -258,12 +258,32 @@ 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.
+Examples include providing Montium specific parameters through LLVM's 
+``\verb TargetData '' class and modifications to the loop unroller to support
+custom policies.
+
 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 transformations 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.
+LLVM to support it is not feasible.
+
+In a few of these cases, this meant that the backend was changed to support more
+features of the LLVM IR. An example of this is finding datapath constants (which
+are the result of a function in MontiumC, so hard to track by LLVM).
+
+In other cases, Recore-specific transformations were added to solve these
+problems. Examples of these are a transformation that removes all global
+variables and passes them as arguments and return values instead, a
+transformation that forcibly inlines all functions marked as ``\verb inline ''
+and a transformation that limits variable lifetimes by introducing extra phi
+nodes.
+
+In a few more cases, the problems are still unresolved, effectively resulting in
+additional constraints on the MontiumC language. Examples of these are
+preventing instructions from being moved out of if/else blocks (which is
+perfectly fine from an LLVM IR standpoint, but does not take into account the
+extra meaning that an if statement has in MontiumIR) and removal of unused bits
+from a constant (which could introduce more different constants than the Montium
+has registers for them).
+
 
 \subsection{New hardware design}
 \label{Pipelining}