Cosmetic fixes.

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

diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex
index 15cf290a487187cc5e3e2c96d703bc57d12467ad..982397a8a2ed8aa802d64a574837e11ffb16db4b 100644 (file)
--- a/Report/Main/Problems/Challenges.tex
+++ b/Report/Main/Problems/Challenges.tex
@@ -33,7 +33,7 @@ makes use of corner cases in the compiler that have been missed in (or left out
 of) the specification, because they will not work reliably in all cases.
 
 The best way to detect these cases is making the compiler check its input using
-an the specification. This way, any code operating outside of the specification
+the specification. This way, any code operating outside of the specification
 can be detected automatically. Writing such checks has not happened yet, mainly
 because the impact of the new hardware on MontiumC is not quite clear yet.
 
@@ -100,7 +100,7 @@ lot of instructions. Second, the code is effectively software pipelined
 to make it run more efficiently.
 
 In figure \ref{ExampleHigh} the same code is displayed, but this time
-using higer level C features (for loops, arra indexing). This is the
+using higer level C features (for loops, array indexing). This is the
 level of code we are trying to achieve, but we're not there yet. It
 should be noted that this is still not "normal" C, since we use the
 "imul" function instead of the normal * operator. However, since the
@@ -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}