diff options
Diffstat (limited to 'content/zettel/3a3.md')
-rw-r--r-- | content/zettel/3a3.md | 47 |
1 files changed, 47 insertions, 0 deletions
diff --git a/content/zettel/3a3.md b/content/zettel/3a3.md new file mode 100644 index 0000000..ec8d9a5 --- /dev/null +++ b/content/zettel/3a3.md @@ -0,0 +1,47 @@ ++++ +title = "Back End" +date = "2020-12-10" +author = "Yann Herklotz" +tags = [] +categories = [] +backlinks = ["3a2"] +forwardlinks = ["3a4"] +zettelid = "3a3" ++++ + +This is where most of the optimisations happen, and where the +intermediate CFG language is finally converted to proper assembly. The +main optimisations are done in RTL, which is a language that models a +CFG and has infinite registers it can choose from, therefore not using a +stack. Optimisations such as inlining, constant propagation and dead +code elimination are all performed at this level, using Kildall's +algorithm to get the necessary analysis to perform these optimisations +\[1\]. + +RTL is then translated to LTL, which is where physical registers are +assigned, and where the rest of the variables are put into the stack. At +this level, the CFG is also translated into a CFG that uses basic blocks +instead of instructions. This is an interesting addition, and I am not +sure why that is not a property of RTL, as basic blocks can make some +optimisations simpler. Optimisations that would affect basic blocks, +such as lazy code motion (LCM) optimisations would be harder if the +language contained basic blocks, as these would have to be changed. As +these optimisations are performed at the RTL level, it does make sense +to have a simpler representation of code at that level and make these +transformations simpler. + +<div id="refs" class="references csl-bib-body" markdown="1"> + +<div id="ref-bertot06_struc_approac_provin_compil_optim" +class="csl-entry" markdown="1"> + +<span class="csl-left-margin">\[1\] +</span><span class="csl-right-inline">Y. Bertot, B. Grégoire, and X. +Leroy, “A structured approach to proving compiler optimizations based on +dataflow analysis,” in *Types for proofs and programs*, J.-C. Filliâtre, +C. Paulin-Mohring, and B. Werner, Eds., Berlin, Heidelberg: Springer +Berlin Heidelberg, 2006, pp. 66–81.</span> + +</div> + +</div> |