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
264 Traditionally ``MemorySSA`` optimized ``MemoryUse``\ s at build-time, up to a
279 restricted ``MemorySSA`` to one operand per access.
337 Because ``MemorySSA`` keeps track of LLVM IR, it needs to be updated whenever
340 If you'd like examples, ``GVNHoist`` and ``LICM`` are users of ``MemorySSA``\ s
350 ``MemorySSA`` only places ``MemoryPhi``\ s where they're actually
398 ``MemorySSA`` is meant to reason about the relation between memory
401 optimizations. Specifically, care must be taken when trying to use ``MemorySSA``
420 Going solely by ``MemorySSA``'s analysis, hoisting the ``load`` to ``entry`` may
430 ``MemorySSA`` in LLVM deliberately trades off precision for speed.
470 results' precision provided by ``MemorySSA``. For example, AliasAnalysis has various
471 caps, or restrictions on looking through phis which can affect what ``MemorySSA``
472 can infer. Changes made by different passes may make MemorySSA either "overly
476 when the result relies on the state aquired by ``MemorySSA`` due to being updated by
478 Passes that use and update ``MemorySSA`` should do so through the APIs provided by the
480 Direct optimizations to ``MemorySSA`` are not permitted.
484 being beyond what ``MemorySSA`` does and them being "free" (i.e. DSE does them anyway).
492 - `2016 LLVM Developers' Meeting: G. Burgess - MemorySSA in Five Minutes <https://www.youtube.com/w…