MemorySSA¶
Introduction¶
MemorySSA
is an analysis that allows us to cheaply reason about the
interactions between various memory operations. Its goal is to replace
MemoryDependenceAnalysis
for most (if not all) use-cases. This is because,
unless you’re very careful, use of MemoryDependenceAnalysis
can easily
result in quadratic-time algorithms in LLVM. Additionally, MemorySSA
doesn’t
have as many arbitrary limits as MemoryDependenceAnalysis
, so you should get
better results, too.
At a high level, one of the goals of MemorySSA
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 heap memory, and associate memory operations with those versions.
This document goes over how MemorySSA
is structured, and some basic
intuition on how MemorySSA
works.
A paper on MemorySSA (with notes about how it’s implemented in GCC) can be found here. Though, it’s relatively out-of-date; the paper references multiple heap partitions, but GCC eventually swapped to just using one, like we now have in LLVM. Like GCC’s, LLVM’s MemorySSA is intraprocedural.
MemorySSA Structure¶
MemorySSA is a virtual IR. After it’s built, MemorySSA
will contain a
structure that maps Instruction
s to MemoryAccess
es, which are
MemorySSA
’s parallel to LLVM Instruction
s.
Each MemoryAccess
can be one of three types:
MemoryPhi
MemoryUse
MemoryDef
MemoryPhi
s are PhiNode
s, but for memory operations. If at any
point we have two (or more) MemoryDef
s that could flow into a
BasicBlock
, the block’s top MemoryAccess
will be a
MemoryPhi
. As in LLVM IR, MemoryPhi
s don’t correspond to any
concrete operation. As such, BasicBlock
s are mapped to MemoryPhi
s
inside MemorySSA
, whereas Instruction
s are mapped to MemoryUse
s
and MemoryDef
s.
Note also that in SSA, Phi nodes merge must-reach definitions (that is, definitions that must 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).
MemoryUse
s are operations which use but don’t modify memory. An example of
a MemoryUse
is a load
, or a readonly
function call.
MemoryDef
s are operations which may either modify memory, or which
introduce some kind of ordering constraints. Examples of MemoryDef
s
include store
s, function calls, load
s with acquire
(or higher)
ordering, volatile operations, memory fences, etc.
Every function that exists has a special MemoryDef
called liveOnEntry
.
It dominates every MemoryAccess
in the function that MemorySSA
is being
run on, and implies that we’ve hit the top of the function. It’s the only
MemoryDef
that maps to no Instruction
in LLVM IR. Use of
liveOnEntry
implies that the memory being used is either undefined or
defined before the function begins.
An example of all of this overlaid on LLVM IR (obtained by running opt
-passes='print<memoryssa>' -disable-output
on an .ll
file) is below. When
viewing this example, it may be helpful to view it in terms of clobbers. The
operands of a given MemoryAccess
are all (potential) clobbers of said
MemoryAccess, and the value produced by a MemoryAccess
can act as a clobber
for other MemoryAccess
es. Another useful way of looking at it is in
terms of heap versions. In that view, operands of of a given
MemoryAccess
are the version of the heap before the operation, and
if the access produces a value, the value is the new version of the heap
after the operation.
define void @foo() {
entry:
%p1 = alloca i8
%p2 = alloca i8
%p3 = alloca i8
; 1 = MemoryDef(liveOnEntry)
store i8 0, i8* %p3
br label %while.cond
while.cond:
; 6 = MemoryPhi({%0,1},{if.end,4})
br i1 undef, label %if.then, label %if.else
if.then:
; 2 = MemoryDef(6)
store i8 0, i8* %p1
br label %if.end
if.else:
; 3 = MemoryDef(6)
store i8 1, i8* %p2
br label %if.end
if.end:
; 5 = MemoryPhi({if.then,2},{if.else,3})
; MemoryUse(5)
%1 = load i8, i8* %p1
; 4 = MemoryDef(5)
store i8 2, i8* %p2
; MemoryUse(1)
%2 = load i8, i8* %p3
br label %while.cond
}
The MemorySSA
IR is shown in comments that precede the instructions they map
to (if such an instruction exists). For example, 1 = MemoryDef(liveOnEntry)
is a MemoryAccess
(specifically, a MemoryDef
), and it describes the LLVM
instruction store i8 0, i8* %p3
. Other places in MemorySSA
refer to this
particular MemoryDef
as 1
(much like how one can refer to load i8, i8*
%p1
in LLVM with %1
). Again, MemoryPhi
s don’t correspond to any LLVM
Instruction, so the line directly below a MemoryPhi
isn’t special.
Going from the top down:
6 = MemoryPhi({entry,1},{if.end,4})
notes that, when enteringwhile.cond
, the reaching definition for it is either1
or4
. ThisMemoryPhi
is referred to in the textual IR by the number6
.2 = MemoryDef(6)
notes thatstore i8 0, i8* %p1
is a definition, and its reaching definition before it is6
, or theMemoryPhi
afterwhile.cond
. (See the Build-time use optimization and Precision sections below for why thisMemoryDef
isn’t linked to a separate, disambiguatedMemoryPhi
.)3 = MemoryDef(6)
notes thatstore i8 0, i8* %p2
is a definition; its reaching definition is also6
.5 = MemoryPhi({if.then,2},{if.else,3})
notes that the clobber before this block could either be2
or3
.MemoryUse(5)
notes thatload i8, i8* %p1
is a use of memory, and that it’s clobbered by5
.4 = MemoryDef(5)
notes thatstore i8 2, i8* %p2
is a definition; it’s reaching definition is5
.MemoryUse(1)
notes thatload i8, i8* %p3
is just a user of memory, and the last thing that could clobber this use is abovewhile.cond
(e.g. the store to%p3
). In heap versioning parlance, it really only depends on the heap version 1, and is unaffected by the new heap versions generated since then.
As an aside, MemoryAccess
is a Value
mostly for convenience; it’s not
meant to interact with LLVM IR.
Design of MemorySSA¶
MemorySSA
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 MemoryAccess
es. You can then query MemorySSA
for things
like the dominance relation between MemoryAccess
es, and get the
MemoryAccess
for any given Instruction
.
When MemorySSA
is done building, it also hands you a MemorySSAWalker
that you can use (see below).
The walker¶
A structure that helps MemorySSA
do its job is the MemorySSAWalker
, or
the walker, for short. The goal of the walker is to provide answers to clobber
queries beyond what’s represented directly by MemoryAccess
es. For example,
given:
define void @foo() {
%a = alloca i8
%b = alloca i8
; 1 = MemoryDef(liveOnEntry)
store i8 0, i8* %a
; 2 = MemoryDef(1)
store i8 0, i8* %b
}
The store to %a
is clearly not a clobber for the store to %b
. It would
be the walker’s goal to figure this out, and return liveOnEntry
when queried
for the clobber of MemoryAccess
2
.
By default, MemorySSA
provides a walker that can optimize MemoryDef
s
and MemoryUse
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 GlobalsAA
, one that always stops at MemoryPhi
nodes, etc).
Locating clobbers yourself¶
If you choose to make your own walker, you can find the clobber for a
MemoryAccess
by walking every MemoryDef
that dominates said
MemoryAccess
. The structure of MemoryDef
s makes this relatively simple;
they ultimately form a linked list of every clobber that dominates the
MemoryAccess
that you’re trying to optimize. In other words, the
definingAccess
of a MemoryDef
is always the nearest dominating
MemoryDef
or MemoryPhi
of said MemoryDef
.
Build-time use optimization¶
MemorySSA
will optimize some MemoryAccess
es at build-time.
Specifically, we optimize the operand of every MemoryUse
to point to the
actual clobber of said MemoryUse
. This can be seen in the above example; the
second MemoryUse
in if.end
has an operand of 1
, which is a
MemoryDef
from the entry block. This is done to make walking,
value numbering, etc, faster and easier.
It is not possible to optimize MemoryDef
in the same way, as we
restrict MemorySSA
to one heap variable and, thus, one Phi node
per block.
Invalidation and updating¶
Because MemorySSA
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 Instructions
. The update API is being made on an as-needed basis.
If you’d like examples, GVNHoist
is a user of MemorySSA
s update API.
Phi placement¶
MemorySSA
only places MemoryPhi
s where they’re actually
needed. That is, it is a pruned SSA form, like LLVM’s SSA form. For
example, consider:
define void @foo() {
entry:
%p1 = alloca i8
%p2 = alloca i8
%p3 = alloca i8
; 1 = MemoryDef(liveOnEntry)
store i8 0, i8* %p3
br label %while.cond
while.cond:
; 3 = MemoryPhi({%0,1},{if.end,2})
br i1 undef, label %if.then, label %if.else
if.then:
br label %if.end
if.else:
br label %if.end
if.end:
; MemoryUse(1)
%1 = load i8, i8* %p1
; 2 = MemoryDef(3)
store i8 2, i8* %p2
; MemoryUse(1)
%2 = load i8, i8* %p3
br label %while.cond
}
Because we removed the stores from if.then
and if.else
, a MemoryPhi
for if.end
would be pointless, so we don’t place one. So, if you need to
place a MemoryDef
in if.then
or if.else
, you’ll need to also create
a MemoryPhi
for if.end
.
 Because we have Walkers that are capable of optimizing above said
phis, doing so shouldn’t prohibit optimizations.
Non-Goals¶
MemorySSA
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 MemorySSA
to reason about atomic or volatile operations, as in:
define i8 @foo(i8* %a) {
entry:
br i1 undef, label %if.then, label %if.end
if.then:
; 1 = MemoryDef(liveOnEntry)
%0 = load volatile i8, i8* %a
br label %if.end
if.end:
%av = phi i8 [0, %entry], [%0, %if.then]
ret i8 %av
}
Going solely by MemorySSA
’s analysis, hoisting the load
to entry
may
seem legal. Because it’s a volatile load, though, it’s not.
Design tradeoffs¶
Precision¶
MemorySSA
in LLVM deliberately trades off precision for speed.
Let us think about memory variables as if they were disjoint partitions of the
heap (that is, if you have one variable, as above, it represents the entire
heap, and if you have multiple variables, each one represents some
disjoint portion of the heap)
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 heap 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.
Each of these variables may be clobbered at multiple def sites.
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).
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.
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.
As a result, LLVM partitions to one variable.
Use Optimization¶
Unlike other partitioned forms, LLVM’s MemorySSA
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.


Nicholas David Preston, Ph.D.
I am a postdoctoral scientist at the UW-Madison Center for Sustainability and the Global Environment (SAGE). My research focuses on the intersection of the environment, computing, and health.
I am a postdoctoral scientist at the UW-Madison Center for Sustainability and the Global Environment (SAGE). My research focuses on the intersection of the environment, computing, and health.
In 2009, I joined SAGE as the project director for
Healthscapesa suite of web tools for finding, analyzing, and
sharing global environmental health information. Our goal is to
initiate a community-driven open source project to facilitate research on the
environmental determinants of global health. Our research
is currently being applied to infectious disease outbreaks
and health monitoring during natural disasters. Healthsacpes is
in an early release for developers; we aim to extend a stable
release to the research community by summer 2011. For more information
please visit healthscapes.org


Smart Calculator
insert a number and let calculator do the magic!
and
Addition:
Subtraction:
Division:
Multiplication:
Remainder:
Exponentiation:


Python Package Management in ArcGIS Pro Using Conda
Clinton Dow
Overview of Conda in ArcGIS Pro
What is Conda?
- Python virtual environment and package manager
- Multiple instances of python.exe and supporting files
- Easily add/remove 3rd party code to projects
- Automates dependency handling
- Subset of Anaconda functionality
- Does not include all packages
- Command Line Interface only, no GUI
- Additional features supporting https://anaconda.org/
- Open Source, written in Python
Product Story
- ArcGIS heavily dependent on Python, shipped with specific version
- Locked-in to package versions ie: NumPy, SciPy
- Broken Python env breaks the application
- No package management
- Python Ecosystem becoming more robust
- Data Science/Visualization
- Machine Learning
- Scientific Libraries
- Desire for enhanced sharing experience
- Handles requirements
- Ease of distribution
Virtual Environments
- Concept
- ‘Virtual Machine Lite’
- Allows multiple side-by-side Pythons on one machine
- Different configurations for each Python installation
- Conda Environments
- Package Dependency SAT Solver
- Stored in the folder within the Pro installation
- Simply a folder on disk, nothing fancy
- Cheap to create, disposable/iterable
- Easy to replicate with metadata
Packages
- Concept
- Small units of functionality added to a kernel
- Unix/Linux concept (apt-get, yum, etc)
- Not Python exclusive (npm, nuget, etc)
- Versioning Friendly
- Multiple versions available at one time
- Each version may depend on different, additional packages
- Similar to shipping a package from a retailer
- Ingredients, Warning Labels, Instruction Manual
Package Structure
- Python Packaging Authority
- https://www.pypa.io/en/latest/
- https://packaging.python.org/distributing/
- Sample Github Project
- https://github.com/pypa/sampleproject
Channels
- Concept
- A source of related packages
- A TV channel is a source of related shows
- Public Channel
- Hosted on anaconda.org
- Free to create
- Similar to a public github repository
- Private Channel
- A webserver which hosts packages
- As customizable as any other web service
Anaconda.org Contributors and Organizations
- Similar structure to github organization/user repos
Channels (.condarc file) Structure
- Anaconda.org usernames as channel names
- Private Server as http://channel-name
- Local File as file:///file-name
Private Repository
- Simply a webserver hosting .tar.bz2 files
- Indexed with ‘conda index’ to create repodata.json
Scalability
- Packages easily deploy as webservices
- Container ecosystem (Docker etc)
- Automate setup of new workstations
- Saves times for Sys Admins
- Distribute to as few or as many users as required
- Leverage open-source Python packages to save time and costs
- Thousands of useful packages freely available
- Becoming an industry-standard Python utility
- Increased familiarity
- Lowered complexity of onboarding
ArcGIS Pro 2.0
- Enhanced Environment Control in the User Interface
- Integration with R tools and the r-python bridge for ArcGIS
ArcGIS Pro 2.1
- Adding packaging and channel support
- ArcPy package


Ameol for Windows
The latest version of Ameol for Windows is $(version)
Version $(version)
- Improved mail message decoding.
- Updated application icon and bitmaps.
Version 2.70.2302
- Removed modem/TAPI support.
Version 2.65.2202
- Fix CIX support phone numbers, URLs and addresses.
- Default to /lite mode for new installs going forward.
- Settings are now saved in the INI file as well as the registry.
- Incorporated steveren's fix for the Wine emulation issue.
- Improved UI for SMTP and POP3 settings on Settings->Mail tab.
- Warning when mailbox approaches 2GB limit and no further e-mail will be collected.
- Maximum number of days to leave mail on the server increased from 7 to 90 days.
Version 2.64.2132
- Fixed a bug which caused resigned topics to be marked locally as un-resigned when rejoining a single topic in the same forum.
- Fixed a bug which caused Ameol's main window to appear off-screen when restarted.
Version 2.63.2122
- Added exit.scr which issues 'opt syncpointers y q' to sync Ameol pointers with forums.
Version 2.63.2121
- Remove redundant scripts.
- Fix time formatting bug where AM/PM appear in 24-hour times.
Version 2.63.2120
- Added Check for Updates to Help menu and remove the CoSy check for update option.
- Fix crash with long URL links.
Version 2.63.2117
- Added "Retrieve the ban list for a forum" script.
- Added "Retrieve the user's own ban list" script.
Version 2.62.2114
- Add CIX Support Web Site link to Help menu.
- Fix mail reply subject line issue with 'Re:'.
- Add ability to configure SMTP and POP3 port number for mail servers.
Version 2.62.2112
- Add Ban and Unban commands to Participants dialog. These presently only work on v4.conferencing.co.uk. Ban will ban one or more participants from the selected conference. Unban will prompt for a participant to unban from the selected conference. You need to be a moderator of the conference to ban and unban participants.
Version 2.62.2110
- Clean up Help->Report options and template.
Version 2.62.2109
- Undo the change for quotes in the mail To/CC/BCC field for now as that was breaking the address book.
- Add back modems.ini for people who still use them.
- Update CIX dial-up phone number to<PHONE_NUMBER>9.
/body>


Validation provides a means to ensure the user is inputting usable data into a form. Form validation can be expressed to a user initially by denoting required inputs with the required symbol; or, after a user enters invalid information into the form through warnings and invalid states.
Provide a method for verifying user input is desired and usable information.
Pristine input fields are fields which have not been interacted with. A pristine field that is in an invalid state should not appear to be in an invalid state (i.e. do not display red border, validation messages, or icons). After the user interacts with the input, apply invalid state styles.
The required field element should be applied to all required input fields. This element is meant to be used in regular or complex forms that have three or more input fields. Not all forms will need to use the require field notification. For example, a sign in page often includes a form with username and password input fields. These inputs are understood to be required to sign in, but usually don't include a required mark.
A "required" note is not necessary at the bottom of the form since the require asterisk is widely used and understood
Use the following three methods to instruct the user when a user requires additional information to complete a form field.
Inline label hints must always be placed inside of parenthesis. The hint should be clear, short, and helpful.
Validation messages placed after the input are visible only after the user has interacted with the input. The text should be read and easy to read. Messages should be clear, short, and helpful. For longer messages use the info icon method (see below).
If your hint text is too complex for the other methods, use an info icon and tooltip. Clicking/Hovering the info icon displays a tooltip. The tooltip should not contain extensive documentation or instructions. It should contain just enough to instruct the user on how to complete the input.
Form messages are used when portions of the form are not visible to the user (ex: in tabs, accordions, or tile grids). The message should appear at the top of the form and should instruct the user that additional changes are required to complete the form.
Tile grids hide information about each element in the grid. Form messages make it obvious to the user that a tile in the tile grid requires additional attention. The offending tile should similarly be marked as invalid.
Accordions hide information about each section. Form messages make it obvious to the user that a section of the accordion requires additional attention. The offending section should similarly be marked as invalid.
Sometimes it may be necessary to validate user input on a server. A loader clearly indicates to the user that validation is occurring. When the validation is complete indicate to the user the result of the validation with status icons. In the event that validation fails, clicking on the info icon should present a tooltip with additional information to correct the error.
Asynchronous validation should be de-bounced to allow the user to complete input before validation occurs. This prevents validation from occurring on each keystroke.