Lines Matching refs:MemorySSA

2 MemorySSA  title
11 ``MemorySSA`` is an analysis that allows us to cheaply reason about the
15 result in quadratic-time algorithms in LLVM. Additionally, ``MemorySSA`` doesn't
17 better results, too. One common use of ``MemorySSA`` is to quickly find out
21 At a high level, one of the goals of ``MemorySSA`` is to provide an SSA based
27 This document goes over how ``MemorySSA`` is structured, and some basic
28 intuition on how ``MemorySSA`` works.
30 A paper on MemorySSA (with notes about how it's implemented in GCC) `can be
34 GCC's, LLVM's MemorySSA is intraprocedural.
37 MemorySSA Structure
40 MemorySSA is a virtual IR. After it's built, ``MemorySSA`` will contain a
42 ``MemorySSA``'s parallel to LLVM ``Instruction``\ s.
76 inside ``MemorySSA``, whereas ``Instruction``\ s are mapped to ``MemoryUse``\ s
80 definitions that *must* be new versions of variables). In MemorySSA, PHI nodes
88 It dominates every ``MemoryAccess`` in the function that ``MemorySSA`` is being
155 The ``MemorySSA`` IR is shown in comments that precede the instructions they map
158 instruction ``store i8 0, i8* %p3``. Other places in ``MemorySSA`` refer to this
190 Design of MemorySSA
193 ``MemorySSA`` is an analysis that can be built for any arbitrary function. When
195 mapping of ``MemoryAccess``\ es. You can then query ``MemorySSA`` for things
199 When ``MemorySSA`` is done building, it also hands you a ``MemorySSAWalker``
206 A structure that helps ``MemorySSA`` do its job is the ``MemorySSAWalker``, or
227 By default, ``MemorySSA`` provides a walker that can optimize ``MemoryDef``\ s
249 ``MemorySSA`` will optimize some ``MemoryAccess``\ es at build-time.
257 restrict ``MemorySSA`` to one memory variable and, thus, one Phi node
264 Because ``MemorySSA`` keeps track of LLVM IR, it needs to be updated whenever
267 If you'd like examples, ``GVNHoist`` is a user of ``MemorySSA``\ s update API.
273 ``MemorySSA`` only places ``MemoryPhi``\ s where they're actually
321 ``MemorySSA`` is meant to reason about the relation between memory
324 optimizations. Specifically, care must be taken when trying to use ``MemorySSA``
343 Going solely by ``MemorySSA``'s analysis, hoisting the ``load`` to ``entry`` may
353 ``MemorySSA`` in LLVM deliberately trades off precision for speed.
392 Unlike other partitioned forms, LLVM's ``MemorySSA`` does make one