simple efficient ssa

[neel-patel-1]

No description provided.

[sampsyo]

Thanks for getting this post started, and for giving it a shot relatively early in the semester!

I am concerned that some of the claims you make about this paper are too strong and lack evidence. I think the problem is that you have mostly simplified specific, technical criticisms into broader, blanket statements that may be impossible to justify with convincing arguments. I have left specific references in the review, but my main suggestion here is to take a step back and think carefully about which arguments you think you can justify and which are too broad to be really justifiable.

[sampsyo]

Because this is a blog post for the web and not a paper, you can just link the relevant text instead of using bracketed footnotes. Like this:

[Static single assignment (SSA) form][ssa] and the first efficient…

[ssa]: https://compilers.cs.uni-saarland.de/ssasem/talks/Kenneth.Zadeck.pdf

Then people can just click the link, instead of clicking the link to find the link to click.

[neel-patel-1]

changed to use name form throughout, but removed references section. Feel free to let me know if keeping the references section is preferred

[sampsyo]

"each variable is assigned exactly once": This definition kinda leaves out the "static" part of the definition, and could be misinterpreted as saying that they are only assigned once dynamically (which admittedly would not make much sense).

[neel-patel-1]

corrected to emphasize that each program's variable assignment has a unique name

[sampsyo]

While this is all true, it doesn’t quite set up the salient contrast with the next paragraph. Namely, one big contrast here is that Cytron starts with a CFG while the paper you are summarizing does not need a CFG at all (much less a domtree for that CFG). This description kinda buries that big difference.

[neel-patel-1]

Made explicit that Cytron et al.'s takes the CFG as input to better set up the next paragraph

[sampsyo]

While I'm flattered that you attribute this to observation me, it is self-evident from the publication dates of the papers. :)

[neel-patel-1]

obvio

[sampsyo]

This is false. You can disprove it with a quick google search for the terms "simple and efficient" ssa site:github.com, which yields several compiler projects that reference this paper. That's what I did to construct this list during the discussion period:
#488 (reply in thread)

[neel-patel-1]

Referenced the the projects you found that use Simple and Efficient SSA. Interesting that MemorySSA uses it. Also found this paper that cites Braun et al., but can't tell if the compiler (Triton) actually uses it

[sampsyo]

These arguments need more development in order to be convincing. Namely:

• “much more complexity than what the paper emphasizes”: To justify this claim, you would to have to give a list of additional sources of complexity and somehow argue that the magnitude is large (for that “very”).
• “This is especially apparent in the context of compiler programmers working with this direct translation approach”: You have not presented any arguments for why this approach would complicate the lives of programmers; you have just stated it. Can you think through how you would construct an argument to support your claim?
• “there is also complexity within the actual algorithm regarding mechanisms such as sealing blocks”: Now I am no longer sure what you mean by “complexity.” Because you’re comparing two algorithms, maybe you mean asymptotic complexity, i.e., big-O running time? Or maybe you just mean how long and detailed the pseudocode looks? If the latter, how did you compare the two? If you’re going to say this, you need to make a convincing argument, with evidence, for the actual difference you are thinking of.
• “Additionally, in many cases our future passes will rely on dominance data structures.” This seems like a completely different argument, about efficiency instead of simplicity. At the very least, this seems to deserve its own paragraph so you can fully develop this separate argument?
• “only be valuable when applied to certain use cases”: At the very least, it seems like you must say what those use cases are (or what they are not). “Certain” use cases is too vague.
• “lots of boilerplate for the syntax of different languages”: You need more sentences here to convincingly develop this argument. What you are implicitly assuming here, but not directly stating, is that we want to build a compiler framework (like LLVM) with a single IR to support many different languages. In that setting, maybe you want those frontends to be easy to write. If so, maybe it’s nicer to have a CFG IR you can generate without doing SSA first. But none of these arguments apply if you’re just building one compiler, not a framework. So I don't think it's just "particularly the case" for frameworks; it's only the case for frameworks.
• "The paper made loose claims": That sounds pretty broadly negative, and it's hard to tell exactly which claims you're referring to (to decide whether the paper actually made those claims). When what I think you mean to summarize here is "the paper only showed empirical results about specific claim X. Specific claim Y would be nice, but the paper did not evaluate it." Then, separately, you may or may not want to add on "the paper says that claim Y is true, but we don't have the evidence." I think it is EXTREMELY important, when you are criticizing a paper for overclaiming, that you both (a) clearly demonstrate that they actually made a specific claim, and (b) clearly delineate the lack of evidence for that claim. It is a bad idea to vaguely gesture at categories of claims they may or may not have made.

Overall, I would recommend these steps:

1. Carefully make a list of all the criticisms you want to make.
2. Decide which ones you have actual arguments or evidence for. Discard the ones where you do not have substantiation.
3. Rewrite each criticism as a standalone paragraph that includes both a clear statement of the criticism itself and convincing evidence to support it.

By mashing things together into one long paragraph, I worry that you can too easily hide the fact that the criticisms have insufficiently detailed support.

[neel-patel-1]

Updated the Merits/Shortcomings to reflect and substantiate the claims we aimed to make:

List of merits:

• Constructing alternative program representations and data structures can incur significant overhead, due to the runtime of the algorithm and the corresponding memory allocations. By eliminating the construction of the dominance-related data structures, in some scenarios, the end-to-end compilation time may be reduced.
• By integrating on-the-fly optimizations into the SSA construction procedure, the algorithm could be useful when compiling in time-constrained scenarios (e.g., just-in-time compilers), where there may not be time to run a separate pass to perform an optimization.
• Some compilers enthusiasts in CS6120 found the algorithm to be unique and thought the proofs of some of its properties were elegant. Specifically, we appreciated the use of recursion to calculate phi nodes lazily and the use of strongly connected components to prove that the algorithm minimized the number of phi functions placed throughout the SSA IR.

List of criticisms:

• Simple, Efficient SSA may make maintainability more challenging:
  • Because Braun et al.'s algorithm goes straight from the AST to SSA form, the compiler's front-end may become more complex. Specifically, any modularity afforded by first converting a language-dependent AST into a CFG is lost. While this may be fine for compilers targeting a single language, compiler frameworks, like LLVM, implement front-ends for multiple languages. It may become burdensome for front-end developers to always have to implement Braun et al.'s algorithm. Some developers may prefer to transform the AST into a simpler non-SSA IR, and a framework that separates these concerns seems simpler to maintain.
  • The proposed algorithm enables the use of on-the-fly optimizations performed at SSA construction time. While useful, these are implemented as modifications to the SSA construction implementation, which could lead to code churn or introduce bugs.
• Loss of data structures which may be useful for other passes
  • Since Braun et al.'s algorithm does not rely on the dominance frontier or dominator tree, these data structures would not be created at SSA construction time. If later analyses or optimizations that use these data structures are performed, much of the speedup from Braun et al.'s algorithm may be lost to subsequent passes. For example, the dominates relation is required to determine whether it is safe to perform loop-invariant code motion and the dominator tree is used for contification which can expose function inlining opportunities.
• Hard to tell whether the proposed algorithm reduces SSA construction time significantly
  • It certainly seems reasonable that a front-end based on Braun et al.'s algorithm could significantly speed up end-to-end compilation. However, Braun et al.'s implementation in LLVM 3.1 only executed 0.28% fewer instructions in when compiling all programs in the SPEC CINT2000 suite. It is worth noting that their implementation was not as highly tuned as the baseline LLVM implementation they compared against.
  • It is also worth noting that some compilers and tools have begun adopting Braun et al.'s algorithm for SSA conversion, lending credence to the author's claim that direct AST-to-SSA could provide non-negligible speedups. For example, a SPIR-V-Tools pass converts SPIR-V functions directly into SSA form using Braun et al.'s algorithm. The Memory SSA analysis, which builds an SSA-like representation for LLVM memory operations, also uses the marker algorithm presented by Braun et al. Also, the MIR project, which focuses on building JIT compilers currently uses Braun et al.'s algorithm for SSA construction.

[neel-patel-1]

@sampsyo Thanks for taking the time to review and leave feedback. After reviewing and addressing the comments, we will update the PR.