X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fprojects%2Finternship.git;a=blobdiff_plain;f=Report%2FMain%2FProblems%2FChallenges.tex;h=1fccb19c67e23c98f22ceacbd8d6f1e66c6ed673;hp=b92430ba198363eea0e0b88cc9b0512ef1e1846d;hb=0ac3f8b7cfb60e71b9f95dc8bf1752e1e971685f;hpb=1ae051d27cb9debbfa570ac82846c8a8d86287f2 diff --git a/Report/Main/Problems/Challenges.tex b/Report/Main/Problems/Challenges.tex index b92430b..1fccb19 100644 --- a/Report/Main/Problems/Challenges.tex +++ b/Report/Main/Problems/Challenges.tex @@ -12,12 +12,12 @@ was ``whatever the compiler eats''. To be able to create a proper set of transformations, the constraints on the input and output of that transformation process should be properly specified. This entails two parts: Specifying the MontiumC language, and specifying the -Montium IR constraints, which is is the input to the backend. +Montium IR constraints, which is the input to the backend. Specifying Montium IR was relatively easy, since it is defined directly by the -backend. The MontiumC specification is slightly more complex. There are two +backend. The MontiumC specification was slightly more complex. There are two different angles to it: What does the compiler support, and what do we want the -compiler to support. +compiler to support? \subsubsection{What is supported?} One angle for looking at MontiumC is seeing what the compiler can currently @@ -34,7 +34,7 @@ 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 the specification. This way, any code operating outside of the specification -can be detected automatically. Writing such checks has not happened yet, mainly +can be detected automatically. Writing such checks has not happened so far, mainly because the impact of the new hardware on MontiumC is not quite clear yet. Existing transformations, on the other hand, might miss a few corner cases. When @@ -49,8 +49,8 @@ specification. This way, corner cases exposed by the testing code can be detected automatically. A framework for this testing has been set up and partially filled with small tests. -Building this initial specification did pose a number of challenges. Since -simply trying all possible C features to see if they are accepted by the +Building this initial specification did pose a number of challenges. +Simply trying all possible C features to see if they are accepted by the MontiumC compiler and thus valid MontiumC is a lengthy process and only useful in a limited way. A more constructive way would be to examine the compiler components to see what transformations are applied and from that derive the @@ -69,7 +69,7 @@ specification of MontiumC, since the base specification only supports a few C features. \subsubsection{What is wanted?} -A completely different angle of looking at this is from the requirements point +A completely different angle of looking at this specification is from the requirements point of view. What do we want MontiumC to support? This angle is even harder than the previous one, since there are a lot of levels of requirements. Ideally, MontiumC would not exist and our compiler would support the C language fully. However, @@ -83,7 +83,7 @@ anything is mappable, but with a simple compiler this will not result in the most efficient code. In the Montium case, a lot of things simply cannot be mapped on the hardware at all. -Considering that our ideal is not reachable (Though the new hardware might take +Considering that our ideal is not reachable (though the new hardware might take us a lot closer), every feature considered for MontiumC was evaluated thoroughly for feasibility, both in hardware and in the compiler. In practice, this meant that new language features would be @@ -118,7 +118,7 @@ out of the specification. It is not unlikely that the specification is still incorrect in a few places (or rather, that the code does not implement the specification properly). Since -so far there has been not any automated checking of programs against the +so far there has not been any automated checking of programs against the specification, these errors have not been uncovered. Once the new hardware is more clearly defined and the MontiumC specification is updated for it, this checking should be added so the specification and compiler can be better @@ -196,10 +196,10 @@ out rather hard (it's still not included currently). Working with this pass did prove very insightful, however, as to how the LLVM framework is built and what its possibilities are. -Additionally, during my working with the code in this internship I also produced +Additionally, during my working with the code during this internship I also produced a number of patches for LLVM, containing bugfixes, some cleanup and documentation improvements. Since the best way to integrate with any open source -project seems to be contributing code, I was giving commit access to the LLVM +project seems to be contributing code, I was given commit access to the LLVM tree not long thereafter. This access has proved very useful during the rest of the internship, since it was now a a lot easier to make (simple) changes to the LLVM framework to better suit the needs of Recore. @@ -210,7 +210,7 @@ Any changes that are directly required by the Montium frontend and the LLVM chan need are obvious. However, usually when making changes to the main LLVM tree, just changing enough for Recore is not engough for LLVM. Since the LLVM code must work on any program, not just MontiumC programs, extra changes are -required (see also parapgrah \ref{StayingGeneric}). This is also an issue of +required (see also parapgrah \ref{StayingGeneric}). Additionally, this is an issue of building up credit within the LLVM community: The more you contribute to LLVM, the more influence you have when things need changing. @@ -234,7 +234,7 @@ other one as well. Compiler changes also require hardware support, so working with the hardware developers was not uncommon either. In practice, most communication with the hardware developers went through the backend developer, except for the design discussion concerning the new Montium -hardware design (also see section \ref{Pipelining} below). +hardware design (also see section \ref{Pipelining}). In addition, discussions regarding design issues at various levels often happen out in the open, which invites people with an opinion about something to @@ -279,7 +279,7 @@ 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 +perfectly fine from an LLVM IR point of view, 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). @@ -291,8 +291,8 @@ I've also been involved for a bit with the instruction scheduling algorithm required for the new (pipelined) hardware design and the hardware design itself. Even though this is completely outside of the area of my assignment, the initial prototype of that scheduler was created by someone else using LLVM. Because of -my experience with LLVM, I have been assisting him with that. Initially mostly -helping out with hints on LLVM coding, but later also with thinking about the +my experience with LLVM, I have been assisting him with it. Initially I +helped him by giving hints on LLVM coding, but later also with thinking about the scheduler and hardware design. I will not go into much detail about the new hardware and its scheduler here, @@ -339,14 +339,14 @@ first and last few iterations (the prologue and epilogue) are distinctly different from the loop "kernel", the number of instructions needed for a pipelined loop can easily increase a lot. -However, all pipelined loops share a very distinct structure (first +However, all pipelined loops share a very distinct structure: first stage 1, then stage 1+2, then stage 1+2+3, etc, then all stages at the -same time, similar for the epilogue). Also, every instruction in the +same time, similar for the epilogue. Also, every instruction in the prologue and epilogue are a strict subset of the instructions in the kernel. By adding some hardware support for exactly this structure, the code size increase for the prologue and epilogue can be effectively reduced to a fixed number of instructions (which take the number of stages as a -parameter and uses preloaded instructions with explicit stage annotation). +parameter and use preloaded instructions with explicit stage annotation). The tradeoff here is that this hardware is only usable specifically for these inner loops, any other code will leave this extra hardware unused. However, @@ -365,7 +365,7 @@ but those will be a lot smaller than the full instruction). On the new hardware, however, function calls are more powerful, which should lead to a lot less code duplication. For this reason, putting every instruction in configuration registers might actually take more space instead of less. It -should be noted that, the configuration registers of the old Montium are +should be noted that the configuration registers of the old Montium are effectively a compiler controlled cache that is mandatory and static (instructions must be in the cache and the cache cannot be modified at runtime). By lifting these limitations, we get a cache that is a lot more flexible.