SSA stands for Static Single Assignment. It is a property of program representations (usually IR) designed for enabling various optimizations. Instead of 'normal' variables that can be assigned multiple times, SSA variables can only be assigned once. Such form allows the compiler to do more efficient register allocation because it is easy to approximate how many variables are live at any given point in the program.
Branches in SSA form need special handling because variables can have different values after the branches join depending on which branch was executed. For this purpose SSA form uses the so-called Phi(ϕ) function. The Phi functions are entered by the compiler roughly to the points right before branch dependent values of a variable are used. The precise points are defined for example by using Dominance Frontiers.
Dominance frontier of a CFG (Control Flow Graph) node is the set of nodes that dominate a predecessor of the node but are not necessarily strict dominators of the node. Efficient algorithm for determining the dominance frontiers of nodes was presented by Ron Cytron et al. in the paper http://dl.acm.org/citation.cfm?doid=115372.115320
For more detailed information on SSA refer to
Constructing SSA in LLVM
The LLVM IR requires SSA form by definition. However compiling c with LLVM / Clang to LLVM IR without optimizations doesn't appear to generate code in SSA form. By default the variables are handled as stack variables by allocating them with 'alloca'. For example:
The trick here is that while register values are required to be in SSA form, memory objects are not required / permitted to be in SSA form. This design allows for compiler frontends (such as clang) to generate LLVM IR without having to perform the potentially complex transformations from source language to strict SSA. Convention which LLVM frontend developers are encouraged to follow is to generate LLVM IR with all mutable variables handled as memory variables. This means each mutable variable becomes a stack allocation. The alloca / store / load is very inefficient way of handling simple local variables and the code generated from such IR is slow. The idea of using such representation is to keep the transformation of the variables to registers in a single highly optimized part of LLVM and allow for frontend developers to generate IR more simply.
In LLVM the transformation from stack variables to register values is performed in optimization passes. Running a mem2reg optimization pass on the IR will transform memory objects to register values whenever possible (or the heuristics say so). The optimization pass is implemented in PromoteMemoryToRegister.cpp which analyzes the BasicBlocks and the alloca instructions for PHINode placement. The PHINode placement is calculated with algorithm by Sreedhar and Gao that has been modified to not use the DJ (Dominator edge, Join edge) graphs. According to Sreedhar and Gao the algorithm is approximately five times faster on average than the Cytron et al. algorithm. The speed gain results from calculating dominance frontiers for only nodes that potentially need phi nodes and well designed data structures.
Curiosity: LLVM used to contain exactly the Cytron et al algorithm in http://llvm.org/docs/doxygen/html/DominanceFrontierImpl_8h_source.html but it's now deprecated.
A good introduction to SSA in LLVM can be found at http://llvm.org/docs/tutorial/OCamlLangImpl7.html
SSA in LLVM IR
Example of generating the IR, with and without phi-nodes, for the code studied in the individual assignment 2.
IR representation of the example1.c, without phi-nodes presented in example1-no-opt.ll below. This can be created with command clang -S -emit-llvm ./example1.c -o example1-no-opt.ll. Notice, how all the variables (a, b, c, d, e) are kept in the stack memory instead of registers.
IR representation of the example1.c, with phi-nodes presented in example1-opt.ll below. This can be created with command clang -S -emit-llvm ./example1.c -o /dev/stdout | opt -S -mem2reg -o example1-opt.ll. Notice that all the variables are stored in the registers, unlike in the example above, where stack memory was used. The result is otherwise exactly the same as the one seen in the example solution for the exercise 2, except that there is no optimizations done for the the code. For example, there still exists useless labels (label 5, label 13), and some dead code (line 18).
PromoteMemToReg ( http://llvm.org/docs/doxygen/html/PromoteMemToReg_8h.html )
The mem2reg optimisation pass is implemented in the PromoteMemToReg.cpp file. The mem2reg pass takes the major responsibility of converting IR to SSA representation. PromoteMemToReg exposes an interface to promote alloca instructions to SSA registers, by using the SSA construction algorithm.
"PHINode - The PHINode class is used to represent the magical mystical PHI node, that can not exist in nature, but can be synthesized in a computer scientist's overactive imagination." [http://llvm.org/docs/doxygen/html/Instructions_8h_source.html]. PHINode is called from PromoteMemToReg, when there exists a value that should be converted to a phi-node.
ScalarReplAggregates ( http://llvm.org/docs/doxygen/html/Transforms_2Scalar_8h_source.html )
ScalarReplAggregate is used to transform the aggregate type (structs, arrays) alloca instructions in the LLVM IR into the SSA form. In practice, ScalarReplAggregates tries to break the alloca instructions of the arrays or structs into a individual instructions and, if possible, turns those individual instructions to phi-nodes.