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}