{"id":16251593,"url":"https://github.com/pfalcon/awesome-program-analysis","last_synced_at":"2026-01-20T22:02:21.141Z","repository":{"id":37407165,"uuid":"156601429","full_name":"pfalcon/awesome-program-analysis","owner":"pfalcon","description":"Program Analisys and Transformation survey and links (particular focus on SSA)","archived":false,"fork":false,"pushed_at":"2021-03-22T05:21:15.000Z","size":16,"stargazers_count":166,"open_issues_count":1,"forks_count":25,"subscribers_count":9,"default_branch":"master","last_synced_at":"2025-11-05T06:05:30.593Z","etag":null,"topics":["control-flow-analysis","phi-functions","register-allocators","ssa-construction","ssa-form"],"latest_commit_sha":null,"homepage":"","language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/pfalcon.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-11-07T20:02:47.000Z","updated_at":"2025-10-26T19:50:10.000Z","dependencies_parsed_at":"2022-08-08T20:15:33.495Z","dependency_job_id":null,"html_url":"https://github.com/pfalcon/awesome-program-analysis","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/pfalcon/awesome-program-analysis","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pfalcon%2Fawesome-program-analysis","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pfalcon%2Fawesome-program-analysis/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pfalcon%2Fawesome-program-analysis/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pfalcon%2Fawesome-program-analysis/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/pfalcon","download_url":"https://codeload.github.com/pfalcon/awesome-program-analysis/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/pfalcon%2Fawesome-program-analysis/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28615559,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-20T21:52:42.722Z","status":"ssl_error","status_checked_at":"2026-01-20T21:52:20.513Z","response_time":117,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["control-flow-analysis","phi-functions","register-allocators","ssa-construction","ssa-form"],"created_at":"2024-10-10T15:10:43.484Z","updated_at":"2026-01-20T22:02:21.124Z","avatar_url":"https://github.com/pfalcon.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"Program Analysis and Transformation Survey and Links\n====================================================\n\nTable of Contents:\n\n* [Glossary](#glossary)\n* [Names](#names)\n* [Intermediate Representation Forms/Types](#intermediate-representation-formstypes)\n* [SSA Form](#ssa-form)\n  * [Classification of SSA types](#classification-of-ssa-types)\n  * [History](#history)\n  * [Construction Algorithms](#construction-algorithms)\n  * [Deconstruction Algorithms](#deconstruction-algorithms)\n* [Control Flow Analysis](#control-flow-analysis)\n* [Alias Analysis](#alias-analysis)\n* [Register Allocation](#register-allocation)\n* [Projects](#projects)\n\nGlossary\n========\n\n* Critical edge (of a graph) - Edge between a vertex which also has other successors and a vertex which has other predecessors.\n  [(wikipedia)](https://en.wikipedia.org/wiki/Control-flow_graph#Special_edges)\n* DCE - Dead Code Elimination [(wikipedia)](https://en.wikipedia.org/wiki/Dead_code_elimination)\n* Graph - [(wikipedia)](https://en.wikipedia.org/wiki/Graph_(discrete_mathematics))\n* LOLSSA - *[ this entry is a joke! due to [lolspeak](https://www.researchgate.net/profile/Jill_Vaughan/publication/323620982_I_can_haz_language_play_The_construction_of_language_and_identity_in_LOLspeak/links/5aa089e8aca272d448b178b6/I-can-haz-language-play-The-construction-of-language-and-identity-in-LOLspeak.pdf) ]*\n  a) SSA as defined in some early papers on the matter, especially\n  in the part of out-of-SSA conversion (see epigraph to\n  [SSA Deconstruction](#deconstruction-algorithms) section below);\n  b) a similar version of SSA used in some (oftentimes amateur) projects\n  decades later.\n\nNames\n=====\n\nAs a dedication:\n\nWe study Program Analysis because it's objective and complex phenomena of\nnature devoid of subjectivities of the mankind. But then, we can't separate\nit from the work of great human minds who laid the paths in this area, whose\nsteps we now follow.\n\nThese are people who contributed to the Program Analysis field of study\n(with all the apology to many more who are not listed here). The emphasis\nhere is on well-knownness and public availability of their works:\n\n* Gregory Chaitin\n* Jeffrey Ullman\n* Alfred Aho\n* [Keith Cooper](http://keith.rice.edu/)\n  * thesis: 1983 \"Interprocedural Data Flow Analysis in a Programming Environment\"\n* [Andrew Appel](https://www.cs.princeton.edu/~appel/)\n  * thesis: 1985 \"Compile-time Evaluation and Code Generation in Semantics-Directed Compilers\"\n  * book 1998: \"Modern Compiler Implementation in ML/Java/C\"\n  * 2000: [Optimal Register Coalescing Challenge](https://www.cs.princeton.edu/~appel/coalesce/)\n* [Preston Briggs](https://genealogy.math.ndsu.nodak.edu/id.php?id=94538)\n  * thesis: 1992 \"Register Allocation via Graph Coloring\"\n* [Clifford Click](http://cliffc.org/blog/sample-page/) [@cliffclick](https://github.com/cliffclick)\n  * thesis: 1995 \"Combining Analyses, Combining Optimizations\"\n* [John Aycock](https://pages.cpsc.ucalgary.ca/~aycock/)\n  * thesis: 2001 \"Practical Earley Parsing and the SPARK Toolkit\"\n  * Hacked on Python compilation: [[1]](https://pages.cpsc.ucalgary.ca/~aycock/papers/ucpy.pdf), [[2]](https://prism.ucalgary.ca/handle/1880/45370), [[3]](https://pages.cpsc.ucalgary.ca/~aycock/papers/ipc7-211.pdf), [[4]](https://pages.cpsc.ucalgary.ca/~aycock/papers/ipc8.pdf)\n  * Now hacks on retrogaming: [[1]](https://www.amazon.com/Retrogame-Archeology-Exploring-Computer-Games/dp/3319300024), [[2]](https://www.youtube.com/watch?v=WV259iLon1M)\n* [Sebastian Hack](http://compilers.cs.uni-saarland.de/people/hack/)\n  * thesis: 2006 \"Register Allocation for Programs in SSA Form\"\n* [Matthias Braun](https://pp.ipd.kit.edu/personhp/matthias_braun.php) [@MatzeB](https://github.com/MatzeB)\n  * thesis: 2006 \"Heuristisches Auslagern in einem SSA-basierten Registerzuteiler\" in German, \"Heuristic spilling in an SSA-based register allocator\"\n* [Sebastian Buchwald](https://pp.ipd.kit.edu/personhp/sebastian_buchwald.php)\n  * thesis: 2008 \"Befehlsauswahl auf expliziten Abhangigkeitsgraphen\" in German, \"Instruction selection on explicit dependency graphs\"\n* [Florent Bouchez](http://florent.bouchez.free.fr/)\n  * thesis: 2009 \"A Study of Spilling and Coalescing in Register Allocation as Two Separate Phases\"\n* [Benoit Boissinot](https://bboissin.appspot.com/)\n  * thesis: 2010 \"Towards an SSA based compiler back-end: some interesting properties of SSA and its extensions\"\n* Quentin Colombet\n  * thesis 2012: \"Decoupled (SSA-based) Register Allocators: from Theory to Practice, Coping with Just-In-Time Compilation and Embedded Processors Constraints\"\n\nIntermediate Representation Forms/Types\n=======================================\n\n* Imperative\n* Functional\n  * Static Single-Assignment (SSA) - As argued by Appel, SSA is a functional representation.\n  * (Lambda-)Functional\n  * Continuation-passing Style (CPS)\n\nSSA Form\n========\n\nPut simple, in an SSA program, each variable is (statically, syntactically)\nassigned only once.\n\nWikipedia: https://en.wikipedia.org/wiki/Static_single_assignment_form\n\nGeneral reference: \"SSA Book\" aka \"Static Single Assignment Book\" aka\n\"SSA-based Compiler Design\" is open, collaborative effort of many SSA\nresearchers to write a definitive reference for all things SSA.\n* Direct download (new versions are published):\n  http://ssabook.gforge.inria.fr/latest/book-full.pdf\n* Download directory:\n  http://ssabook.gforge.inria.fr/latest/\n* GForge project: https://gforge.inria.fr/projects/ssabook/\n* Subversion repository:\n  https://gforge.inria.fr/scm/browser.php?group_id=1950\n\nClassification of SSA types\n---------------------------\n\n* Axis 1: Minimality. There're 2 poles: fully minimal vs fully maximal SSA form.\n  Between those, there's continuum of intermediate cases.\n  * Fully maximal\n    * Defined e.g. by Appel:\n      \u003e A really crude approach is to split every variable at every basic-block\n      \u003e boundary, and put φ-functions for every variable in every block.\n\n      Maximal form is the most intuitive form for construction, gives the simplest\n      algorithms for both phi insertion and variable renaming phases of the\n      construction.\n  * Optimized maximal\n    * An obvious optimization of avoiding placing phi functions in blocks with\n      a single predecessor, as they never needed there. While cuts the number\n      of phi functions, makes renaming algorithm a bit more complex: while for\n      maximal form renaming could process blocks in arbitrary order (because\n      each of program's variables has a local definition in every basic block),\n      optimized maximal form requires processing predecessor first for each\n      such single-predecessor block.\n  * Minimal for reducible CFGs\n    * Some algorithms (e.g. optimized for simplicity) naturally produce minimal\n      form only for reducible CFGs. Applied to non-reducible CFGs, they may\n      generate extra Phi functions. There're usually extensions to such\n      algorithms to generate minimal form even for non-reducible CFGs too (but\n      such extensions may add noticeable complexity to otherwise \"simple\"\n      algorithm). Examplem of such an algorithm ins 2013 Braun et al.\n  * Fully minimal\n    * This is usually what's sought for SSA form, where there're no superflous\n      phi functions, based only on graph properties of the CFG (with consulting\n      semantics of the underlying program).\n* Axis 2: Prunedness. As argued (implied) by 2013 Braun et al., prunedness is\n  a separate trait from minimality. E.g., their algorithm constructs not fully\n  minimal, yet pruned form. Between pruned and non-pruned forms, there're\n  intermediate types again.\n  * Pruned\n    * Minimal form can still have dead phi functions, i.e. phi functions which\n      reference variables which are not actually used in the rest of the program.\n      Note that such references are problematic, as they artificially extend live\n      ranges of referenced variables. Likewise, it defines new variables which\n      aren't really live. The pruned SSA form is devoid of the dead phi functions.\n      Two obvious way to achieve this: a) perform live variable analysis prior to\n      SSA construction and use it to avoid placing dead phi functions; b) run\n      dead code elimination (DCE) pass after the construction (which requires\n      live variable analysis first, this time on SSA form of the program already).\n      Due to these additional passes, pruned SSA construction is more expensive\n      than just the minimal form. Note that if we intend to run DCE pass on the\n      program anyway, which is often happens, we don't really need to be concerned\n      to *construct* pruned form, as we will get it after the DCE pass \"for free\".\n      Except of course that minimal and especially maximal form require more\n      space to store and more time to go thru it during DCE.\n  * Semi-pruned\n    * Sometimes called \"Briggs-Minimal\" form. A compromise between fully\n      pruned and minimal form. From Wikipedia:\n      \u003e Semi-pruned SSA form[6] is an attempt to reduce the number of Φ\n      functions without incurring the relatively high cost of computing\n      live variable information. It is based on the following observation:\n      if a variable is never live upon entry into a basic block, it never\n      needs a Φ function. During SSA construction, Φ functions for any\n      \"block-local\" variables are omitted.\n  * Not pruned\n* Axis 2: Conventional vs Transformed SSA\n  * Conventional\n    * Allows for easy deconstruction algorithm (literally, just drop\n      SSA variables subscripts and remove Phi functions). Usually,\n      after construction, SSA is in conventional form (if during\n      construction, additional optimizations were not performed).\n  * Transformed\n    * Some optimizations applied to an SSA program make simple deconstruction\n      algorithm outlined above not possible (not producing correct\n      results). This is known as \"transformed SSA\". There're algorithms\n      to convert transformed SSA into conventional form.\n* Axis 3: Strict vs non-strict SSA\n  * Non-strict SSA allows some variables to be undefined on some paths\n    (just like conventional imperative programs).\n  * Strict form requires each use to be dominated by definition. This\n    in turn means that every variable must be explicitly initialized.\n    Non-strict program can be trivially converted into strict form, by\n    initializing variables with special values, like \"undef\" for truly\n    undefined values, \"param\" for function paramters, etc. Most of SSA\n    algorithms requires/assume strict SSA form, so non-strict is not\n    further considered.\n\n\nDiscussion: There's one and true SSA type - the maximal one. It has a\nstraightforward, easy to understand construction algorithm which does\nnot depend on any other special algorithms. Running a generic\nDCE algorithm on it will remove any redundancies of the maximal form\n(oftentimes, together with other dead code). All other types are\noptimizations of the maximal form, allowing to generate less Phi\nfunctions, so less are removed later. Optimizations are useful, but\nthe usual warning about premature optimization applies.\n\nHistory\n-------\n\n* 1969\n\nAccording to Aycock/Horspool:\n\n\u003e The genesis of SSA form was in the 1960s with the work of Shapiro and\nSaint [23,19]. Their conversion algorithm was based upon finding equivalence\nclasses of variables by walking the control-flow graph.\n\nR. M. Shapiro and H. Saint. The Representation of Algorithms. Rome Air\nDevelopment Center TR-69-313, Volume II, September 1969.\n\n\u003e Given the possibility of concurrent operation, we might also wish to question the automatic one-one mapping of variable names to equipment locations. Two uses of the same variable name might be entirely unrelated in terms of data dependency and thus potentially concurrent if mapped to different equipment locations.\n\nContinues on the p.31 of the paper (p.39 of the PDF) under the title:\n\n\u003e VI. Variable-Names and Data Dependency Relations\n\n* 1988\n\nThen, following Wikipedia, \"SSA was proposed by Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck in 1988.\"\nBarry Rosen; Mark N. Wegman; F. Kenneth Zadeck (1988). \"Global value numbers and redundant computations\"\n\nConstruction Algorithms\n-----------------------\n\nBased on excerpts from \"Simple Generation of Static Single-Assignment Form\",\nAycock/Horspool\n\n### For Reducible CFGs (i.e. special case)\n\n* 1986 R. Cytron, A. Lowry, K. Zadeck. Code Motion of Control Structures in High-Level\n  Languages. Proceedings of the Thirteenth Annual ACM Symposium on Principles\n  of Programming Languages, 1986, pp. 70–85.\n\n  \u003e Cytron, Lowry, and Zadeck [11] predate the use of φ-functions, and employ\n  a heuristic placement policy based on the interval structure of the control-flow\n  graph, similar to that of Rosen, Wegman, and Zadeck [22]. The latter work is\n  interesting because they look for the same patterns as our algorithm does during\n  our minimization phase. However, they do so after generating SSA form, and\n  then only to correct ‘second order effects’ created during redundancy elimination.\n\n* 1994 Single-Pass Generation of Static Single-Assignment Form for Structured Languages, Brandis and Mössenböck\n\n  \u003e Brandis and Mössenböck [5] generate SSA form in one pass for structured control-\n  flow graphs, a subset of reducible control-flow graphs, by delicate placement of\n  φ-functions. They describe how to extend their method to reducible control-flow\n  graphs, but require the dominator tree to do so.\n\n* 2000 Simple Generation of Static Single-Assignment Form, 2000, John Aycock and Nigel Horspool\n\n  \u003e In this paper we present a new, simple method for converting to SSA\n  form, which produces correct solutions for nonreducible control-flow\n  graphs, and produces minimal solutions for reducible ones.\n\n### For Non-Reducible CFGs (i.e. general case)\n\n* 1991 R. Cytron, J. Ferrante, B. K. Rosen, M. N. Wegman, and F. K. Zadeck. Efficiently\n  Computing Static Single-Assignment Form and the Control Dependence Graph.\n  ACM TOPLAS 13, 4 (October 1991), pp. 451–490.\n\n  \u003e \"Canonical\" SSA construction algorithm.\n\n  * 1995 R. K. Cytron and J. Ferrante. Efficiently Computing φ-Nodes On-The-Fly. ACM\n    TOPLAS 17, 3 (May 1995), pp. 487–506.\n\n    \u003e Cytron and Ferrante [9] later refined their method so that it runs in almost-linear time.\n\n* 1994 R. Johnson, D. Pearson, and K. Pingali. The Program Structure Tree: Computing\n  Control Regions in Linear Time. ACM PLDI ’94, pp. 171–185.\n\n  \u003e Johnson, Pearson, and Pingali [16] demonstrate conversion to SSA form as\n  an application of their “program structure tree,” a decomposition of the control-\n  flow graph into single-entry, single-exit regions. They claim that using this graph\n  representation allows them to avoid areas in the control-flow graph that do not\n  contribute to a solution.\n\n* 1995 V. C. Sreedhar and G. R. Gao. A Linear Time Algorithm for Placing φ-Nodes.\n  Proceedings of the Twenty-Second Annual ACM Symposium on Principles of\n  Programming Languages, 1995, pp. 62–73.\n\n  \u003e Sreedhar and Gao [24] devised a linear-time algorithm for φ-function\n  placement using DJ-graphs, a data structure which combines the dominator tree\n  with information about where data flow in the program merges.\n\n* 2013 M. Braun, S. Buchwald, S. Hack, R. Leißa, C. Mallon, and\n  A. Zwinkau. Simple and efficient construction of static single assignment\n  form. In R. Jhala and K. Bosschere, editors, Compiler Construction,\n  volume 7791 of Lecture Notes in Computer Science, pp.\n  102–122. Springer, 2013. doi: 10.1007/978-3-642-37051-9_6.\n\n  \u003e Braun, et al present a simple SSA construction algorithm, which allows\n  direct translation from an abstract syntax tree or bytecode into an\n  SSA-based intermediate representation. The algorithm requires no prior\n  analysis and ensures that even during construction the intermediate representation\n  is in SSA form. This allows the application of SSA-based optimizations\n  during construction. After completion, the intermediate representation\n  is in minimal and pruned SSA form. In spite of its simplicity,\n  the runtime of the algorithm is on par with Cytron et al.’s algorithm.\n\n  * 2016 Verified Construction of Static Single Assignment Form, Sebastian Buchwald,\n    Denis Lohner, Sebastian Ullrich\n\nDeconstruction Algorithms\n-------------------------\n\n---\nEpigraph (due to [Boissinot](https://bboissin.appspot.com/static/upload/bboissin-outssa-cgo09-slides.pdf), slide 20):\n\n*Naively, a k-input Phi-function at entrance to a node X can\nbe replaced by k ordinary assignments, one at the end of\neach control flow predecessor of X. This is always correct...*\n\n-- *Cytron, Ferrante, Rosen, Wegman, Zadeck (1991)\nEfficiently computing static single assignment form and the control\ndependence graph.*\n\n\u003e Cytron et al. (1991): Copies in predecessor basic blocks.\n\nIncorrect!\n* Bad understanding of parallel copies\n* Bad understanding of critical edges and interference\n\n\u003e Briggs et al. (1998)\n\nBoth problems identified. General correctness unclear.\n\n\u003e Sreedhar et al. (1999)\n\nCorrect but:\n* handling of complex branching instructions unclear\n* interplay with coalescing unclear\n* \"virtualization\" hard to implement\n\nMany SSA optimizations turned off in gcc and Jikes.\n\n---\n\nTBD. Some papers in the \"Construction Algorithms\" section also include\ninformation/algorithms on deconstruction.\n\nConverting out of SSA is effectively elimination (lowering) of Phi\nfunctions. (Note that Phi functions may appear in a program which is\nnot (purely) SSA, so Phi elimination is formally more general process\nthan conversion out of SSA.)\n\nThere are 2 general ways to eliminate Phi functions:\n\n1. **Requires splitting critical edges, but doesn't introduce new variables\n   and extra copies**:\n   Treat Phi functions as parallel copies on the incoming edges. This\n   requires splitting critical edges. Afterwards, parallel copies are\n   sequentialized.\n2. **Does not require splitting critical edges, but introduces new\n   variables and extra copies to them which then would need to be\n   coalesced**:\n   For Conventional SSA (CSSA), result and arguments of a Phi can\n   be just renamed to the same name (throughout the program), and the Phi\n   removed. This is because arguments and result do not interfere among\n   themselves (CSSA is produced by normal SSA construction algorithms, which\n   don't perform copy propagation and value numbering during construction).\n   Arbitrary SSA (or Transformed SSA, TSSA) can be converted to CSSA\n   by splitting live ranges of Phi arguments and results, by renaming them\n   to new variables, then inserting parallel copy of old argument variables\n   to new at the end of each predecessor, and parallel copy of all Phi\n   results, after all the Phi functions of the current basic block. These\n   parallel copies (usually) can be sequentialized trivially (so oftentimes\n   even not treated as parallel in the literature). This method does not\n   require splitting critical edges, but introduces many unnecessary copies\n   (intuitively, for non-interfering Phi variables), which then need to\n   be optimized by coalescing (or alternatively, unneeded copies should\n   not be introduced in the first place).\n\nControl Flow Analysis\n=====================\n\nAccording to 1997 Muchnick:\n\n* Analysis on \"raw\" graphs, using dominators, the iterative dataflow algorithms\n* Interval Analysis, which then allows to use adhoc optimized dataflow analysis.\n  Variants in the order of advanceness:\n  * The simplest form is T1-T2 reduction\n  * Maximal intervals analysis\n  * Minimal intervals analysis\n  * Structural analysis\n\n\nAlias Analysis\n==============\n\n* 1994 [Program Analysis and Specialization for the C Programming Language](http://www.cs.cornell.edu/courses/cs711/2005fa/papers/andersen-thesis94.pdf),\n  Lars Andersen\n\n\nRegister Allocation\n===================\n\nWikipedia: https://en.wikipedia.org/wiki/Register_allocation\n\nTerms:\n\n* Decoupled allocator - In classic register allocation algorithms, variables\n  assignment to registers and spilling of non-assignable variables are\n  tightly-coupled, interleaving phases of the single algorithm. In a decoupled\n  allocator, these phases are well separated, with spilling algorithm first\n  selecting and rewriting spilling variables, and assignment algorithm then\n  dealing with the remaining variables. Most of decoupled register allocators\n  are SSA-based, though recent developments also include decoupled allocators\n  for standard imperative programs.\n* Chordal graph - A type of graph, having a property that it can be colored\n  in polynomial time (whereas generic graphs require NP time for coloring).\n  Interference graphs of SSA programs are chordal. (Note that arbitrary\n  pre-coloring and/or register aliasing support for chordal graphs, as\n  required for real-world register allocation, may push complexity back into\n  NP territory).\n\nConventional Register Allocation\n--------------------------------\n\nTBD\n\nRegister Allocation on SSA Form\n-------------------------------\n\n* [University of Saarland page on SSA register allocation](http://compilers.cs.uni-saarland.de/projects/ssara/)\n  gives a good overview of Register Allocation area, and how SSA form makes\n  some matters easier.\n\n\nProjects\n========\n\nAcademic projects\n-----------------\n\n* [SUIF1](https://suif.stanford.edu/suif/suif1/index.html) - 1994, Stanford University\n  * \"The SUIF (Stanford University Intermediate Format) 1.x compiler,\n    developed by the Stanford Compiler Group, is a free infrastructure\n    designed to support collaborative research in optimizing and\n    parallelizing compilers.\"\n* [SUIF2](https://suif.stanford.edu/suif/suif2/index.html) - 1999, Stanford University\n  * \"A new version of the SUIF compiler system, a free infrastructure\n    designed to support collaborative research in optimizing and\n    parallelizing compilers. It is currently in the beta test stage\n    of development.\"\n* Machine SUIF aka machsuif - \"Fork\" of SUIF1/SUIF2, Harvard University\n  * https://web.archive.org/web/20090630022924/http://www.eecs.harvard.edu/machsuif/software/software.html (via archive.org)\n  * http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15745-s02/public/doc/overview.html\n* [NCI (National Compiler Infrastructure)](https://suif.stanford.edu/suif/NCI/) ([archive.org](https://web.archive.org/web/20090901021758/http://www.cs.virginia.edu/nci/)) - 1998-200x? Collaborative project among US universities\n  * \"the National Compiler Infrastructure project has two components:\"\n  * SUIF\n  * [Zephyr](https://web.archive.org/web/20090310184351/http://www.cs.virginia.edu/zephyr/)\n    * Zephyr ASDL now lives at http://asdl.sourceforge.net/\n      * Zephyr ASDL description used in Python: https://github.com/python/cpython/blob/master/Parser/Python.asdl\n      * Oilshell blog post dedicated to Zephyr ASDL: https://www.oilshell.org/blog/2016/12/11.html\n\n---\nThis list is compiled and maintained by Paul Sokolovsky, and released under\n[Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpfalcon%2Fawesome-program-analysis","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpfalcon%2Fawesome-program-analysis","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpfalcon%2Fawesome-program-analysis/lists"}