From 60e7a1fe0520762ef074f4e434ee96b0a650daa4 Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Mon, 21 Jul 2008 18:15:02 +0200 Subject: [PATCH] Add section on staying generic. --- Report/Main/Problems/Challenges.tex | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex index 2d85cf6..2782eee 100644 --- a/Report/Main/Problems/Challenges.tex +++ b/Report/Main/Problems/Challenges.tex @@ -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 -- 2.30.2