HCoop / hcoop / debian / mlton.git / blame
| Commit | Line | Data |
|---|---|---|
| 7f918cf1 CE |
1 | <!DOCTYPE html>\r |
| 2 | <html lang="en">\r | |
| 3 | <head>\r | |
| 4 | <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">\r | |
| 5 | <meta name="generator" content="AsciiDoc 8.6.9">\r | |
| 6 | <title>RefFlatten</title>\r | |
| 7 | <link rel="stylesheet" href="./asciidoc.css" type="text/css">\r | |
| 8 | <link rel="stylesheet" href="./pygments.css" type="text/css">\r | |
| 9 | \r | |
| 10 | \r | |
| 11 | <script type="text/javascript" src="./asciidoc.js"></script>\r | |
| 12 | <script type="text/javascript">\r | |
| 13 | /*<![CDATA[*/\r | |
| 14 | asciidoc.install();\r | |
| 15 | /*]]>*/\r | |
| 16 | </script>\r | |
| 17 | <link rel="stylesheet" href="./mlton.css" type="text/css">\r | |
| 18 | </head>\r | |
| 19 | <body class="article">\r | |
| 20 | <div id="banner">\r | |
| 21 | <div id="banner-home">\r | |
| 22 | <a href="./Home">MLton 20180207</a>\r | |
| 23 | </div>\r | |
| 24 | </div>\r | |
| 25 | <div id="header">\r | |
| 26 | <h1>RefFlatten</h1>\r | |
| 27 | </div>\r | |
| 28 | <div id="content">\r | |
| 29 | <div id="preamble">\r | |
| 30 | <div class="sectionbody">\r | |
| 31 | <div class="paragraph"><p><a href="RefFlatten">RefFlatten</a> is an optimization pass for the <a href="SSA2">SSA2</a>\r | |
| 32 | <a href="IntermediateLanguage">IntermediateLanguage</a>, invoked from <a href="SSA2Simplify">SSA2Simplify</a>.</p></div>\r | |
| 33 | </div>\r | |
| 34 | </div>\r | |
| 35 | <div class="sect1">\r | |
| 36 | <h2 id="_description">Description</h2>\r | |
| 37 | <div class="sectionbody">\r | |
| 38 | <div class="paragraph"><p>This pass flattens a <span class="monospaced">ref</span> cell into its containing object.\r | |
| 39 | The idea is to replace, where possible, a type like</p></div>\r | |
| 40 | <div class="listingblock">\r | |
| 41 | <div class="content monospaced">\r | |
| 42 | <pre>(int ref * real)</pre>\r | |
| 43 | </div></div>\r | |
| 44 | <div class="paragraph"><p>with a type like</p></div>\r | |
| 45 | <div class="listingblock">\r | |
| 46 | <div class="content monospaced">\r | |
| 47 | <pre>(int[m] * real)</pre>\r | |
| 48 | </div></div>\r | |
| 49 | <div class="paragraph"><p>where the <span class="monospaced">[m]</span> indicates a mutable field of a tuple.</p></div>\r | |
| 50 | </div>\r | |
| 51 | </div>\r | |
| 52 | <div class="sect1">\r | |
| 53 | <h2 id="_implementation">Implementation</h2>\r | |
| 54 | <div class="sectionbody">\r | |
| 55 | <div class="ulist"><ul>\r | |
| 56 | <li>\r | |
| 57 | <p>\r | |
| 58 | <a href="https://github.com/MLton/mlton/blob/master/mlton/ssa/ref-flatten.fun"><span class="monospaced">ref-flatten.fun</span></a>\r | |
| 59 | </p>\r | |
| 60 | </li>\r | |
| 61 | </ul></div>\r | |
| 62 | </div>\r | |
| 63 | </div>\r | |
| 64 | <div class="sect1">\r | |
| 65 | <h2 id="_details_and_notes">Details and Notes</h2>\r | |
| 66 | <div class="sectionbody">\r | |
| 67 | <div class="paragraph"><p>The savings is obvious, I hope. We avoid an extra heap-allocated\r | |
| 68 | object for the <span class="monospaced">ref</span>, which in the above case saves two words. We\r | |
| 69 | also save the time and code for the extra indirection at each get and\r | |
| 70 | set. There are lots of useful data structures (singly-linked and\r | |
| 71 | doubly-linked lists, union-find, Fibonacci heaps, …) that I believe\r | |
| 72 | we are paying through the nose right now because of the absence of ref\r | |
| 73 | flattening.</p></div>\r | |
| 74 | <div class="paragraph"><p>The idea is to compute for each occurrence of a <span class="monospaced">ref</span> type in the\r | |
| 75 | program whether or not that <span class="monospaced">ref</span> can be represented as an offset of\r | |
| 76 | some object (constructor or tuple). As before, a unification-based\r | |
| 77 | whole-program with deep abstract values makes sure the analysis is\r | |
| 78 | consistent.</p></div>\r | |
| 79 | <div class="paragraph"><p>The only syntactic part of the analysis that remains is the part that\r | |
| 80 | checks that for a variable bound to a value constructed by <span class="monospaced">Ref_ref</span>:</p></div>\r | |
| 81 | <div class="ulist"><ul>\r | |
| 82 | <li>\r | |
| 83 | <p>\r | |
| 84 | the object allocation is in the same block. This is pretty\r | |
| 85 | draconian, and it would be nice to generalize it some day to allow\r | |
| 86 | flattening as long as the <span class="monospaced">ref</span> allocation and object allocation "line\r | |
| 87 | up one-to-one" in the same loop-free chunk of code.\r | |
| 88 | </p>\r | |
| 89 | </li>\r | |
| 90 | <li>\r | |
| 91 | <p>\r | |
| 92 | updates occur in the same block (and hence it is safe-for-space\r | |
| 93 | because the containing object is still alive). It would be nice to\r | |
| 94 | relax this to allow updates as long as it can be provedthat the\r | |
| 95 | container is live.\r | |
| 96 | </p>\r | |
| 97 | </li>\r | |
| 98 | </ul></div>\r | |
| 99 | <div class="paragraph"><p>Prevent flattening of <span class="monospaced">unit ref</span>-s.</p></div>\r | |
| 100 | <div class="paragraph"><p><a href="RefFlatten">RefFlatten</a> is safe for space. The idea is to prevent a <span class="monospaced">ref</span>\r | |
| 101 | being flattened into an object that has a component of unbounded size\r | |
| 102 | (other than possibly the <span class="monospaced">ref</span> itself) unless we can prove that at\r | |
| 103 | each point the <span class="monospaced">ref</span> is live, then the containing object is live too.\r | |
| 104 | I used a pretty simple approximation to liveness.</p></div>\r | |
| 105 | </div>\r | |
| 106 | </div>\r | |
| 107 | </div>\r | |
| 108 | <div id="footnotes"><hr></div>\r | |
| 109 | <div id="footer">\r | |
| 110 | <div id="footer-text">\r | |
| 111 | </div>\r | |
| 112 | <div id="footer-badges">\r | |
| 113 | </div>\r | |
| 114 | </div>\r | |
| 115 | </body>\r | |
| 116 | </html>\r |