Static single-assignment form: Difference between revisions

Revision as of 06:09, 29 March 2023

Revision as of 06:12, 29 March 2023

Line 142:

* The [[LLVM]] Compiler Infrastructure uses SSA form for all scalar register values (everything except memory) in its primary code representation. SSA form is only eliminated once register allocation occurs, late in the compile process (often at link time).

* The [[Open64]] compiler uses SSA form in its global scalar optimizer, though the code is brought into SSA form before and taken out of SSA form afterwards. Open64 uses extensions to SSA form to represent memory in SSA form as well as scalar values.

* AsSince ofthe version 4 (released in April 2005) [[GNU Compiler Collection | GCC]], the [[GNU Compiler Collection]], makes extensive use of SSA. The [[front and back ends|frontends]] generate "[[GIMPLE#GENERIC and GIMPLE|GENERIC]]" code that is then converted into "[[GIMPLE#GENERIC and GIMPLE|GIMPLE]]" code by the "gimplifier". High-level optimizations are then applied on the SSA form of "GIMPLE". The resulting optimized intermediate code is then translated into [[Register Transfer Language|RTL]], on which low-level optimizations are applied. The architecture-specific [[Front and back ends|backend]]s finally turn RTL into [[assembly language]].

* [[IBM]]'s open source adaptive [[Java virtual machine]], [[Jikes RVM]], uses extended Array SSA, an extension of SSA that allows analysis of scalars, arrays, and object fields in a unified framework. Extended Array SSA analysis is only enabled at the maximum optimization level, which is applied to the most frequently executed portions of code.

* In 2002, [http://citeseer.ist.psu.edu/721276.html researchers modified] IBM's JikesRVM (named Jalapeño at the time) to run both standard Java [[bytecode]] and a typesafe SSA ([[SafeTSA]]) bytecode class files, and demonstrated significant performance benefits to using the SSA bytecode.