1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
|
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>MemorySSA — LLVM 13 documentation</title>
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
<link rel="stylesheet" href="_static/llvm-theme.css" type="text/css" />
<script id="documentation_options" data-url_root="./" src="_static/documentation_options.js"></script>
<script src="_static/jquery.js"></script>
<script src="_static/underscore.js"></script>
<script src="_static/doctools.js"></script>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="MergeFunctions pass, how it works" href="MergeFunctions.html" />
<link rel="prev" title="Markdown Quickstart Template" href="MarkdownQuickstartTemplate.html" />
<style type="text/css">
table.right { float: right; margin-left: 20px; }
table.right td { border: 1px solid #ccc; }
</style>
</head><body>
<div class="logo">
<a href="index.html">
<img src="_static/logo.png"
alt="LLVM Logo" width="250" height="88"/></a>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
accesskey="I">index</a></li>
<li class="right" >
<a href="MergeFunctions.html" title="MergeFunctions pass, how it works"
accesskey="N">next</a> |</li>
<li class="right" >
<a href="MarkdownQuickstartTemplate.html" title="Markdown Quickstart Template"
accesskey="P">previous</a> |</li>
<li><a href="https://llvm.org/">LLVM Home</a> | </li>
<li><a href="index.html">Documentation</a>»</li>
<li class="nav-item nav-item-1"><a href="UserGuides.html" accesskey="U">User Guides</a> »</li>
<li class="nav-item nav-item-this"><a href="">MemorySSA</a></li>
</ul>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3>Documentation</h3>
<ul class="want-points">
<li><a href="https://llvm.org/docs/GettingStartedTutorials.html">Getting Started/Tutorials</a></li>
<li><a href="https://llvm.org/docs/UserGuides.html">User Guides</a></li>
<li><a href="https://llvm.org/docs/Reference.html">Reference</a></li>
</ul>
<h3>Getting Involved</h3>
<ul class="want-points">
<li><a href="https://llvm.org/docs/Contributing.html">Contributing to LLVM</a></li>
<li><a href="https://llvm.org/docs/HowToSubmitABug.html">Submitting Bug Reports</a></li>
<li><a href="https://llvm.org/docs/GettingInvolved.html#mailing-lists">Mailing Lists</a></li>
<li><a href="https://llvm.org/docs/GettingInvolved.html#irc">IRC</a></li>
<li><a href="https://llvm.org/docs/GettingInvolved.html#meetups-and-social-events">Meetups and Social Events</a></li>
</ul>
<h3>Additional Links</h3>
<ul class="want-points">
<li><a href="https://llvm.org/docs/FAQ.html">FAQ</a></li>
<li><a href="https://llvm.org/docs/Lexicon.html">Glossary</a></li>
<li><a href="https://llvm.org/pubs">Publications</a></li>
<li><a href="https://github.com/llvm/llvm-project//">Github Repository</a></li>
</ul>
<div role="note" aria-label="source link">
<h3>This Page</h3>
<ul class="this-page-menu">
<li><a href="_sources/MemorySSA.rst.txt"
rel="nofollow">Show Source</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3 id="searchlabel">Quick search</h3>
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" />
<input type="submit" value="Go" />
</form>
</div>
</div>
<script>$('#searchbox').show(0);</script>
</div>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="memoryssa">
<h1>MemorySSA<a class="headerlink" href="#memoryssa" title="Permalink to this headline">¶</a></h1>
<div class="contents local topic" id="contents">
<ul class="simple">
<li><p><a class="reference internal" href="#introduction" id="id1">Introduction</a></p></li>
<li><p><a class="reference internal" href="#memoryssa-structure" id="id2">MemorySSA Structure</a></p></li>
<li><p><a class="reference internal" href="#design-of-memoryssa" id="id3">Design of MemorySSA</a></p>
<ul>
<li><p><a class="reference internal" href="#the-walker" id="id4">The walker</a></p>
<ul>
<li><p><a class="reference internal" href="#default-walker-apis" id="id5">Default walker APIs</a></p></li>
<li><p><a class="reference internal" href="#locating-clobbers-yourself" id="id6">Locating clobbers yourself</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#build-time-use-optimization" id="id7">Build-time use optimization</a></p></li>
<li><p><a class="reference internal" href="#invalidation-and-updating" id="id8">Invalidation and updating</a></p>
<ul>
<li><p><a class="reference internal" href="#phi-placement" id="id9">Phi placement</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#non-goals" id="id10">Non-Goals</a></p></li>
<li><p><a class="reference internal" href="#design-tradeoffs" id="id11">Design tradeoffs</a></p>
<ul>
<li><p><a class="reference internal" href="#precision" id="id12">Precision</a></p></li>
<li><p><a class="reference internal" href="#use-optimization" id="id13">Use Optimization</a></p></li>
</ul>
</li>
<li><p><a class="reference internal" href="#llvm-developers-meeting-presentations" id="id14">LLVM Developers Meeting presentations</a></p></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="introduction">
<h2><a class="toc-backref" href="#id1">Introduction</a><a class="headerlink" href="#introduction" title="Permalink to this headline">¶</a></h2>
<p><code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is an analysis that allows us to cheaply reason about the
interactions between various memory operations. Its goal is to replace
<code class="docutils literal notranslate"><span class="pre">MemoryDependenceAnalysis</span></code> for most (if not all) use-cases. This is because,
unless you’re very careful, use of <code class="docutils literal notranslate"><span class="pre">MemoryDependenceAnalysis</span></code> can easily
result in quadratic-time algorithms in LLVM. Additionally, <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> doesn’t
have as many arbitrary limits as <code class="docutils literal notranslate"><span class="pre">MemoryDependenceAnalysis</span></code>, so you should get
better results, too. One common use of <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is to quickly find out
that something definitely cannot happen (for example, reason that a hoist
out of a loop can’t happen).</p>
<p>At a high level, one of the goals of <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is to provide an SSA based
form for memory, complete with def-use and use-def chains, which
enables users to quickly find may-def and may-uses of memory operations.
It can also be thought of as a way to cheaply give versions to the complete
state of memory, and associate memory operations with those versions.</p>
<p>This document goes over how <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is structured, and some basic
intuition on how <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> works.</p>
<p>A paper on MemorySSA (with notes about how it’s implemented in GCC) <a class="reference external" href="http://www.airs.com/dnovillo/Papers/mem-ssa.pdf">can be
found here</a>. Though, it’s
relatively out-of-date; the paper references multiple memory partitions, but GCC
eventually swapped to just using one, like we now have in LLVM. Like
GCC’s, LLVM’s MemorySSA is intraprocedural.</p>
</div>
<div class="section" id="memoryssa-structure">
<h2><a class="toc-backref" href="#id2">MemorySSA Structure</a><a class="headerlink" href="#memoryssa-structure" title="Permalink to this headline">¶</a></h2>
<p>MemorySSA is a virtual IR. After it’s built, <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> will contain a
structure that maps <code class="docutils literal notranslate"><span class="pre">Instruction</span></code>s to <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es, which are
<code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code>’s parallel to LLVM <code class="docutils literal notranslate"><span class="pre">Instruction</span></code>s.</p>
<p>Each <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> can be one of three types:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code></p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code></p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code></p></li>
</ul>
<p><code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>s are operations which may either modify memory, or which
introduce some kind of ordering constraints. Examples of <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>s
include <code class="docutils literal notranslate"><span class="pre">store</span></code>s, function calls, <code class="docutils literal notranslate"><span class="pre">load</span></code>s with <code class="docutils literal notranslate"><span class="pre">acquire</span></code> (or higher)
ordering, volatile operations, memory fences, etc. A <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>
always introduces a new version of the entire memory and is linked with a single
<code class="docutils literal notranslate"><span class="pre">MemoryDef/MemoryPhi</span></code> which is the version of memory that the new
version is based on. This implies that there is a <em>single</em>
<code class="docutils literal notranslate"><span class="pre">Def</span></code> chain that connects all the <code class="docutils literal notranslate"><span class="pre">Def</span></code>s, either directly
or indirectly. For example in:</p>
<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span>b = MemoryDef(a)
c = MemoryDef(b)
d = MemoryDef(c)
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">d</span></code> is connected directly with <code class="docutils literal notranslate"><span class="pre">c</span></code> and indirectly with <code class="docutils literal notranslate"><span class="pre">b</span></code>.
This means that <code class="docutils literal notranslate"><span class="pre">d</span></code> potentially clobbers (see below) <code class="docutils literal notranslate"><span class="pre">c</span></code> <em>or</em>
<code class="docutils literal notranslate"><span class="pre">b</span></code> <em>or</em> both. This in turn implies that without the use of <a class="reference internal" href="#the-walker">The walker</a>,
initially every <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> clobbers every other <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>.</p>
<p><code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>s are <code class="docutils literal notranslate"><span class="pre">PhiNode</span></code>s, but for memory operations. If at any
point we have two (or more) <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>s that could flow into a
<code class="docutils literal notranslate"><span class="pre">BasicBlock</span></code>, the block’s top <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> will be a
<code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>. As in LLVM IR, <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>s don’t correspond to any
concrete operation. As such, <code class="docutils literal notranslate"><span class="pre">BasicBlock</span></code>s are mapped to <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>s
inside <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code>, whereas <code class="docutils literal notranslate"><span class="pre">Instruction</span></code>s are mapped to <code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code>s
and <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>s.</p>
<p>Note also that in SSA, Phi nodes merge must-reach definitions (that is,
definitions that <em>must</em> be new versions of variables). In MemorySSA, PHI nodes
merge may-reach definitions (that is, until disambiguated, the versions that
reach a phi node may or may not clobber a given variable).</p>
<p><code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code>s are operations which use but don’t modify memory. An example of
a <code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code> is a <code class="docutils literal notranslate"><span class="pre">load</span></code>, or a <code class="docutils literal notranslate"><span class="pre">readonly</span></code> function call.</p>
<p>Every function that exists has a special <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> called <code class="docutils literal notranslate"><span class="pre">liveOnEntry</span></code>.
It dominates every <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> in the function that <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is being
run on, and implies that we’ve hit the top of the function. It’s the only
<code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> that maps to no <code class="docutils literal notranslate"><span class="pre">Instruction</span></code> in LLVM IR. Use of
<code class="docutils literal notranslate"><span class="pre">liveOnEntry</span></code> implies that the memory being used is either undefined or
defined before the function begins.</p>
<p>An example of all of this overlaid on LLVM IR (obtained by running <code class="docutils literal notranslate"><span class="pre">opt</span>
<span class="pre">-passes='print<memoryssa>'</span> <span class="pre">-disable-output</span></code> on an <code class="docutils literal notranslate"><span class="pre">.ll</span></code> file) is below. When
viewing this example, it may be helpful to view it in terms of clobbers.
The operands of a given <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> are all (potential) clobbers of said
<code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>, and the value produced by a <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> can act as a clobber
for other <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es.</p>
<p>If a <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> is a <em>clobber</em> of another, it means that these two
<code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es may access the same memory. For example, <code class="docutils literal notranslate"><span class="pre">x</span> <span class="pre">=</span> <span class="pre">MemoryDef(y)</span></code>
means that <code class="docutils literal notranslate"><span class="pre">x</span></code> potentially modifies memory that <code class="docutils literal notranslate"><span class="pre">y</span></code> modifies/constrains
(or has modified / constrained).
In the same manner, <code class="docutils literal notranslate"><span class="pre">a</span> <span class="pre">=</span> <span class="pre">MemoryPhi({BB1,b},{BB2,c})</span></code> means that
anyone that uses <code class="docutils literal notranslate"><span class="pre">a</span></code> is accessing memory potentially modified / constrained
by either <code class="docutils literal notranslate"><span class="pre">b</span></code> or <code class="docutils literal notranslate"><span class="pre">c</span></code> (or both). And finally, <code class="docutils literal notranslate"><span class="pre">MemoryUse(x)</span></code> means
that this use accesses memory that <code class="docutils literal notranslate"><span class="pre">x</span></code> has modified / constrained
(as an example, think that if <code class="docutils literal notranslate"><span class="pre">x</span> <span class="pre">=</span> <span class="pre">MemoryDef(...)</span></code>
and <code class="docutils literal notranslate"><span class="pre">MemoryUse(x)</span></code> are in the same loop, the use can’t
be hoisted outside alone).</p>
<p>Another useful way of looking at it is in terms of memory versions.
In that view, operands of a given <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> are the version
of the entire memory before the operation, and if the access produces
a value (i.e. <code class="docutils literal notranslate"><span class="pre">MemoryDef/MemoryPhi</span></code>),
the value is the new version of the memory after the operation.</p>
<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">void</span> <span class="vg">@foo</span><span class="p">()</span> <span class="p">{</span>
<span class="nl">entry:</span>
<span class="nv">%p1</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="nv">%p2</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="nv">%p3</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="c">; 1 = MemoryDef(liveOnEntry)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p3</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%while.cond</span>
<span class="nl">while.cond:</span>
<span class="c">; 6 = MemoryPhi({entry,1},{if.end,4})</span>
<span class="k">br</span> <span class="k">i1</span> <span class="k">undef</span><span class="p">,</span> <span class="k">label</span> <span class="nv">%if.then</span><span class="p">,</span> <span class="k">label</span> <span class="nv">%if.else</span>
<span class="nl">if.then:</span>
<span class="c">; 2 = MemoryDef(6)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p1</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%if.end</span>
<span class="nl">if.else:</span>
<span class="c">; 3 = MemoryDef(6)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">1</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p2</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%if.end</span>
<span class="nl">if.end:</span>
<span class="c">; 5 = MemoryPhi({if.then,2},{if.else,3})</span>
<span class="c">; MemoryUse(5)</span>
<span class="nv nv-Anonymous">%1</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p1</span>
<span class="c">; 4 = MemoryDef(5)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">2</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p2</span>
<span class="c">; MemoryUse(1)</span>
<span class="nv nv-Anonymous">%2</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p3</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%while.cond</span>
<span class="p">}</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> IR is shown in comments that precede the instructions they map
to (if such an instruction exists). For example, <code class="docutils literal notranslate"><span class="pre">1</span> <span class="pre">=</span> <span class="pre">MemoryDef(liveOnEntry)</span></code>
is a <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> (specifically, a <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>), and it describes the LLVM
instruction <code class="docutils literal notranslate"><span class="pre">store</span> <span class="pre">i8</span> <span class="pre">0,</span> <span class="pre">i8*</span> <span class="pre">%p3</span></code>. Other places in <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> refer to this
particular <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> as <code class="docutils literal notranslate"><span class="pre">1</span></code> (much like how one can refer to <code class="docutils literal notranslate"><span class="pre">load</span> <span class="pre">i8,</span> <span class="pre">i8*</span>
<span class="pre">%p1</span></code> in LLVM with <code class="docutils literal notranslate"><span class="pre">%1</span></code>). Again, <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>s don’t correspond to any LLVM
Instruction, so the line directly below a <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code> isn’t special.</p>
<p>Going from the top down:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">6</span> <span class="pre">=</span> <span class="pre">MemoryPhi({entry,1},{if.end,4})</span></code> notes that, when entering
<code class="docutils literal notranslate"><span class="pre">while.cond</span></code>, the reaching definition for it is either <code class="docutils literal notranslate"><span class="pre">1</span></code> or <code class="docutils literal notranslate"><span class="pre">4</span></code>. This
<code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code> is referred to in the textual IR by the number <code class="docutils literal notranslate"><span class="pre">6</span></code>.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">2</span> <span class="pre">=</span> <span class="pre">MemoryDef(6)</span></code> notes that <code class="docutils literal notranslate"><span class="pre">store</span> <span class="pre">i8</span> <span class="pre">0,</span> <span class="pre">i8*</span> <span class="pre">%p1</span></code> is a definition,
and its reaching definition before it is <code class="docutils literal notranslate"><span class="pre">6</span></code>, or the <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code> after
<code class="docutils literal notranslate"><span class="pre">while.cond</span></code>. (See the <a class="reference internal" href="#build-time-use-optimization">Build-time use optimization</a> and <a class="reference internal" href="#precision">Precision</a>
sections below for why this <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> isn’t linked to a separate,
disambiguated <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>.)</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">3</span> <span class="pre">=</span> <span class="pre">MemoryDef(6)</span></code> notes that <code class="docutils literal notranslate"><span class="pre">store</span> <span class="pre">i8</span> <span class="pre">0,</span> <span class="pre">i8*</span> <span class="pre">%p2</span></code> is a definition; its
reaching definition is also <code class="docutils literal notranslate"><span class="pre">6</span></code>.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">5</span> <span class="pre">=</span> <span class="pre">MemoryPhi({if.then,2},{if.else,3})</span></code> notes that the clobber before
this block could either be <code class="docutils literal notranslate"><span class="pre">2</span></code> or <code class="docutils literal notranslate"><span class="pre">3</span></code>.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryUse(5)</span></code> notes that <code class="docutils literal notranslate"><span class="pre">load</span> <span class="pre">i8,</span> <span class="pre">i8*</span> <span class="pre">%p1</span></code> is a use of memory, and that
it’s clobbered by <code class="docutils literal notranslate"><span class="pre">5</span></code>.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">4</span> <span class="pre">=</span> <span class="pre">MemoryDef(5)</span></code> notes that <code class="docutils literal notranslate"><span class="pre">store</span> <span class="pre">i8</span> <span class="pre">2,</span> <span class="pre">i8*</span> <span class="pre">%p2</span></code> is a definition; its
reaching definition is <code class="docutils literal notranslate"><span class="pre">5</span></code>.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryUse(1)</span></code> notes that <code class="docutils literal notranslate"><span class="pre">load</span> <span class="pre">i8,</span> <span class="pre">i8*</span> <span class="pre">%p3</span></code> is just a user of memory,
and the last thing that could clobber this use is above <code class="docutils literal notranslate"><span class="pre">while.cond</span></code> (e.g.
the store to <code class="docutils literal notranslate"><span class="pre">%p3</span></code>). In memory versioning parlance, it really only depends on
the memory version 1, and is unaffected by the new memory versions generated since
then.</p></li>
</ul>
<p>As an aside, <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> is a <code class="docutils literal notranslate"><span class="pre">Value</span></code> mostly for convenience; it’s not
meant to interact with LLVM IR.</p>
</div>
<div class="section" id="design-of-memoryssa">
<h2><a class="toc-backref" href="#id3">Design of MemorySSA</a><a class="headerlink" href="#design-of-memoryssa" title="Permalink to this headline">¶</a></h2>
<p><code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is an analysis that can be built for any arbitrary function. When
it’s built, it does a pass over the function’s IR in order to build up its
mapping of <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es. You can then query <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> for things
like the dominance relation between <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es, and get the
<code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> for any given <code class="docutils literal notranslate"><span class="pre">Instruction</span></code> .</p>
<p>When <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is done building, it also hands you a <code class="docutils literal notranslate"><span class="pre">MemorySSAWalker</span></code>
that you can use (see below).</p>
<div class="section" id="the-walker">
<h3><a class="toc-backref" href="#id4">The walker</a><a class="headerlink" href="#the-walker" title="Permalink to this headline">¶</a></h3>
<p>A structure that helps <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> do its job is the <code class="docutils literal notranslate"><span class="pre">MemorySSAWalker</span></code>, or
the walker, for short. The goal of the walker is to provide answers to clobber
queries beyond what’s represented directly by <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es. For example,
given:</p>
<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">void</span> <span class="vg">@foo</span><span class="p">()</span> <span class="p">{</span>
<span class="nv">%a</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="nv">%b</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="c">; 1 = MemoryDef(liveOnEntry)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%a</span>
<span class="c">; 2 = MemoryDef(1)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%b</span>
<span class="p">}</span>
</pre></div>
</div>
<p>The store to <code class="docutils literal notranslate"><span class="pre">%a</span></code> is clearly not a clobber for the store to <code class="docutils literal notranslate"><span class="pre">%b</span></code>. It would
be the walker’s goal to figure this out, and return <code class="docutils literal notranslate"><span class="pre">liveOnEntry</span></code> when queried
for the clobber of <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> <code class="docutils literal notranslate"><span class="pre">2</span></code>.</p>
<p>By default, <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> provides a walker that can optimize <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>s
and <code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code>s by consulting whatever alias analysis stack you happen to
be using. Walkers were built to be flexible, though, so it’s entirely reasonable
(and expected) to create more specialized walkers (e.g. one that specifically
queries <code class="docutils literal notranslate"><span class="pre">GlobalsAA</span></code>, one that always stops at <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code> nodes, etc).</p>
<div class="section" id="default-walker-apis">
<h4><a class="toc-backref" href="#id5">Default walker APIs</a><a class="headerlink" href="#default-walker-apis" title="Permalink to this headline">¶</a></h4>
<p>There are two main APIs used to retrieve the clobbering access using the walker:</p>
<ul class="simple">
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryAccess</span> <span class="pre">*getClobberingMemoryAccess(MemoryAccess</span> <span class="pre">*MA);</span></code> return the
clobbering memory access for <code class="docutils literal notranslate"><span class="pre">MA</span></code>, caching all intermediate results
computed along the way as part of each access queried.</p></li>
<li><p><code class="docutils literal notranslate"><span class="pre">MemoryAccess</span> <span class="pre">*getClobberingMemoryAccess(MemoryAccess</span> <span class="pre">*MA,</span> <span class="pre">const</span> <span class="pre">MemoryLocation</span> <span class="pre">&Loc);</span></code>
returns the access clobbering memory location <code class="docutils literal notranslate"><span class="pre">Loc</span></code>, starting at <code class="docutils literal notranslate"><span class="pre">MA</span></code>.
Because this API does not request the clobbering access of a specific memory
access, there are no results that can be cached.</p></li>
</ul>
</div>
<div class="section" id="locating-clobbers-yourself">
<h4><a class="toc-backref" href="#id6">Locating clobbers yourself</a><a class="headerlink" href="#locating-clobbers-yourself" title="Permalink to this headline">¶</a></h4>
<p>If you choose to make your own walker, you can find the clobber for a
<code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> by walking every <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> that dominates said
<code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>. The structure of <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>s makes this relatively simple;
they ultimately form a linked list of every clobber that dominates the
<code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code> that you’re trying to optimize. In other words, the
<code class="docutils literal notranslate"><span class="pre">definingAccess</span></code> of a <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> is always the nearest dominating
<code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> or <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code> of said <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code>.</p>
</div>
</div>
<div class="section" id="build-time-use-optimization">
<h3><a class="toc-backref" href="#id7">Build-time use optimization</a><a class="headerlink" href="#build-time-use-optimization" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> will optimize some <code class="docutils literal notranslate"><span class="pre">MemoryAccess</span></code>es at build-time.
Specifically, we optimize the operand of every <code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code> to point to the
actual clobber of said <code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code>. This can be seen in the above example; the
second <code class="docutils literal notranslate"><span class="pre">MemoryUse</span></code> in <code class="docutils literal notranslate"><span class="pre">if.end</span></code> has an operand of <code class="docutils literal notranslate"><span class="pre">1</span></code>, which is a
<code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> from the entry block. This is done to make walking,
value numbering, etc, faster and easier.</p>
<p>It is not possible to optimize <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> in the same way, as we
restrict <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> to one memory variable and, thus, one Phi node
per block.</p>
</div>
<div class="section" id="invalidation-and-updating">
<h3><a class="toc-backref" href="#id8">Invalidation and updating</a><a class="headerlink" href="#invalidation-and-updating" title="Permalink to this headline">¶</a></h3>
<p>Because <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> keeps track of LLVM IR, it needs to be updated whenever
the IR is updated. “Update”, in this case, includes the addition, deletion, and
motion of <code class="docutils literal notranslate"><span class="pre">Instructions</span></code>. The update API is being made on an as-needed basis.
If you’d like examples, <code class="docutils literal notranslate"><span class="pre">GVNHoist</span></code> is a user of <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code>s update API.</p>
<div class="section" id="phi-placement">
<h4><a class="toc-backref" href="#id9">Phi placement</a><a class="headerlink" href="#phi-placement" title="Permalink to this headline">¶</a></h4>
<p><code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> only places <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>s where they’re actually
needed. That is, it is a pruned SSA form, like LLVM’s SSA form. For
example, consider:</p>
<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">void</span> <span class="vg">@foo</span><span class="p">()</span> <span class="p">{</span>
<span class="nl">entry:</span>
<span class="nv">%p1</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="nv">%p2</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="nv">%p3</span> <span class="p">=</span> <span class="k">alloca</span> <span class="k">i8</span>
<span class="c">; 1 = MemoryDef(liveOnEntry)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">0</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p3</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%while.cond</span>
<span class="nl">while.cond:</span>
<span class="c">; 3 = MemoryPhi({%0,1},{if.end,2})</span>
<span class="k">br</span> <span class="k">i1</span> <span class="k">undef</span><span class="p">,</span> <span class="k">label</span> <span class="nv">%if.then</span><span class="p">,</span> <span class="k">label</span> <span class="nv">%if.else</span>
<span class="nl">if.then:</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%if.end</span>
<span class="nl">if.else:</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%if.end</span>
<span class="nl">if.end:</span>
<span class="c">; MemoryUse(1)</span>
<span class="nv nv-Anonymous">%1</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p1</span>
<span class="c">; 2 = MemoryDef(3)</span>
<span class="k">store</span> <span class="k">i8</span> <span class="m">2</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p2</span>
<span class="c">; MemoryUse(1)</span>
<span class="nv nv-Anonymous">%2</span> <span class="p">=</span> <span class="k">load</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%p3</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%while.cond</span>
<span class="p">}</span>
</pre></div>
</div>
<p>Because we removed the stores from <code class="docutils literal notranslate"><span class="pre">if.then</span></code> and <code class="docutils literal notranslate"><span class="pre">if.else</span></code>, a <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>
for <code class="docutils literal notranslate"><span class="pre">if.end</span></code> would be pointless, so we don’t place one. So, if you need to
place a <code class="docutils literal notranslate"><span class="pre">MemoryDef</span></code> in <code class="docutils literal notranslate"><span class="pre">if.then</span></code> or <code class="docutils literal notranslate"><span class="pre">if.else</span></code>, you’ll need to also create
a <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code> for <code class="docutils literal notranslate"><span class="pre">if.end</span></code>.</p>
<p>If it turns out that this is a large burden, we can just place <code class="docutils literal notranslate"><span class="pre">MemoryPhi</span></code>s
everywhere. Because we have Walkers that are capable of optimizing above said
phis, doing so shouldn’t prohibit optimizations.</p>
</div>
</div>
<div class="section" id="non-goals">
<h3><a class="toc-backref" href="#id10">Non-Goals</a><a class="headerlink" href="#non-goals" title="Permalink to this headline">¶</a></h3>
<p><code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> is meant to reason about the relation between memory
operations, and enable quicker querying.
It isn’t meant to be the single source of truth for all potential memory-related
optimizations. Specifically, care must be taken when trying to use <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code>
to reason about atomic or volatile operations, as in:</p>
<div class="highlight-llvm notranslate"><div class="highlight"><pre><span></span><span class="k">define</span> <span class="k">i8</span> <span class="vg">@foo</span><span class="p">(</span><span class="k">i8</span><span class="p">*</span> <span class="nv">%a</span><span class="p">)</span> <span class="p">{</span>
<span class="nl">entry:</span>
<span class="k">br</span> <span class="k">i1</span> <span class="k">undef</span><span class="p">,</span> <span class="k">label</span> <span class="nv">%if.then</span><span class="p">,</span> <span class="k">label</span> <span class="nv">%if.end</span>
<span class="nl">if.then:</span>
<span class="c">; 1 = MemoryDef(liveOnEntry)</span>
<span class="nv nv-Anonymous">%0</span> <span class="p">=</span> <span class="k">load</span> <span class="k">volatile</span> <span class="k">i8</span><span class="p">,</span> <span class="k">i8</span><span class="p">*</span> <span class="nv">%a</span>
<span class="k">br</span> <span class="k">label</span> <span class="nv">%if.end</span>
<span class="nl">if.end:</span>
<span class="nv">%av</span> <span class="p">=</span> <span class="k">phi</span> <span class="k">i8</span> <span class="p">[</span><span class="m">0</span><span class="p">,</span> <span class="nv">%entry</span><span class="p">],</span> <span class="p">[</span><span class="nv nv-Anonymous">%0</span><span class="p">,</span> <span class="nv">%if.then</span><span class="p">]</span>
<span class="k">ret</span> <span class="k">i8</span> <span class="nv">%av</span>
<span class="p">}</span>
</pre></div>
</div>
<p>Going solely by <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code>’s analysis, hoisting the <code class="docutils literal notranslate"><span class="pre">load</span></code> to <code class="docutils literal notranslate"><span class="pre">entry</span></code> may
seem legal. Because it’s a volatile load, though, it’s not.</p>
</div>
<div class="section" id="design-tradeoffs">
<h3><a class="toc-backref" href="#id11">Design tradeoffs</a><a class="headerlink" href="#design-tradeoffs" title="Permalink to this headline">¶</a></h3>
<div class="section" id="precision">
<h4><a class="toc-backref" href="#id12">Precision</a><a class="headerlink" href="#precision" title="Permalink to this headline">¶</a></h4>
<p><code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> in LLVM deliberately trades off precision for speed.
Let us think about memory variables as if they were disjoint partitions of the
memory (that is, if you have one variable, as above, it represents the entire
memory, and if you have multiple variables, each one represents some
disjoint portion of the memory)</p>
<p>First, because alias analysis results conflict with each other, and
each result may be what an analysis wants (IE
TBAA may say no-alias, and something else may say must-alias), it is
not possible to partition the memory the way every optimization wants.
Second, some alias analysis results are not transitive (IE A noalias B,
and B noalias C, does not mean A noalias C), so it is not possible to
come up with a precise partitioning in all cases without variables to
represent every pair of possible aliases. Thus, partitioning
precisely may require introducing at least N^2 new virtual variables,
phi nodes, etc.</p>
<p>Each of these variables may be clobbered at multiple def sites.</p>
<p>To give an example, if you were to split up struct fields into
individual variables, all aliasing operations that may-def multiple struct
fields, will may-def more than one of them. This is pretty common (calls,
copies, field stores, etc).</p>
<p>Experience with SSA forms for memory in other compilers has shown that
it is simply not possible to do this precisely, and in fact, doing it
precisely is not worth it, because now all the optimizations have to
walk tons and tons of virtual variables and phi nodes.</p>
<p>So we partition. At the point at which you partition, again,
experience has shown us there is no point in partitioning to more than
one variable. It simply generates more IR, and optimizations still
have to query something to disambiguate further anyway.</p>
<p>As a result, LLVM partitions to one variable.</p>
</div>
<div class="section" id="use-optimization">
<h4><a class="toc-backref" href="#id13">Use Optimization</a><a class="headerlink" href="#use-optimization" title="Permalink to this headline">¶</a></h4>
<p>Unlike other partitioned forms, LLVM’s <code class="docutils literal notranslate"><span class="pre">MemorySSA</span></code> does make one
useful guarantee - all loads are optimized to point at the thing that
actually clobbers them. This gives some nice properties. For example,
for a given store, you can find all loads actually clobbered by that
store by walking the immediate uses of the store.</p>
</div>
</div>
<div class="section" id="llvm-developers-meeting-presentations">
<h3><a class="toc-backref" href="#id14">LLVM Developers Meeting presentations</a><a class="headerlink" href="#llvm-developers-meeting-presentations" title="Permalink to this headline">¶</a></h3>
<ul class="simple">
<li><p><a class="reference external" href="https://www.youtube.com/watch?v=bdxWmryoHak">2016 LLVM Developers’ Meeting: G. Burgess - MemorySSA in Five Minutes</a>.</p></li>
<li><p><a class="reference external" href="https://www.youtube.com/watch?v=1e5y6WDbXCQ">2020 LLVM Developers’ Meeting: S. Baziotis & S. Moll - Finding Your Way Around the LLVM Dependence Analysis Zoo</a></p></li>
</ul>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Navigation</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="genindex.html" title="General Index"
>index</a></li>
<li class="right" >
<a href="MergeFunctions.html" title="MergeFunctions pass, how it works"
>next</a> |</li>
<li class="right" >
<a href="MarkdownQuickstartTemplate.html" title="Markdown Quickstart Template"
>previous</a> |</li>
<li><a href="https://llvm.org/">LLVM Home</a> | </li>
<li><a href="index.html">Documentation</a>»</li>
<li class="nav-item nav-item-1"><a href="UserGuides.html" >User Guides</a> »</li>
<li class="nav-item nav-item-this"><a href="">MemorySSA</a></li>
</ul>
</div>
<div class="footer" role="contentinfo">
© Copyright 2003-2021, LLVM Project.
Last updated on 2021-09-18.
Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 3.5.4.
</div>
</body>
</html>
|
