Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Inter-variable Out-of-SSA Coalescing in GCC

January 5, 2016
Alexandre Oliva

Share:

    It was little more than a decade ago that GCC was dragged, kicking and screaming (as Richard T. Henderson put it), into adopting the SSA form for part of the compilation process. RTL remains in use for the later compilation passes, and the conversion out of SSA takes place exactly at the translation from the GIMPLE SSA form to RTL.

    As usual, during this translation, we partition and coalesce SSA versions so as to reduce the number of allocated registers and stack slots and of copy instructions.

    We used to regard, as candidates for coalescing into the same partition, only different versions of the same variable, and anonymous SSA versions (created for some compiler-generated temporaries) with the same type.

    That was not as bad as it sounded:  the copyrename pass, executed several times per compiled function, identified copies between versions of different variables and changed the variable of one of them, so as to
    enable them to coalesce into the same partition. Unfortunately changing variables was often confusing when tracking down gcc bugs by analyzing intermediate representations.

    Before we introduced variable tracking at assignments (VTA), such changes also severely impacted
    debug information generation. Copyrename passes used to refrain from renaming SSA versions of non-inlined user-visible variables, to reduce the debug information impact, but after VTA was introduced, we could lift this restriction, since copyrename no longer affected debug information. Although the debug information issue had already been addressed, copyrename still affected GCC dumps.

    Most of all, the copyrename passes were wasteful, because the out-of-SSA pass also examined all SSA copy statements. It just rejected, as candidates for coalescing, those that didn't copy between versions of
    the same variable. There was room for improvement.

    Furthermore, copyrename would not rename for coalescing versions of different function parameters, nor would it operate on versions of the function result. There was a good reason for that: unlike normal
    variables, parameters and results are handled in a special way by the out-of-SSA conversion, because RTL for them had to be allocated and initialized with the incoming arguments by the code that dealt with
    various calling convention details, as opposed to just being assigned pretty much any uninitialized (pseudo-)register or stack slot. These special requirements only applied to the actual incoming values; other versions did not have to be so limited, so there was room for improvement there too.

    Finally, out-of-SSA created declarations to serve as the variable for each set of coalesced anonymous SSA versions. Avoiding this small waste of compile time and memory was desirable.

    GCC PR64164 provided us with the excuse we needed to tackle these long-standing wishes for improvement.

    Ideally, we'd be able to deal with parameters and results within a function just as if they were like any other variable, and we'd separate the code that dealt with extracting incoming parameter values from
    their incoming locations from the code that stored them in their function-internal initial locations.

    Given the number of different targets with different calling conventions idiosyncrasies, making significant changes to the calling-convention code was found to be too risky, and it wouldn't get us better generated code or a more maintainable compiler.

    So, we avoided excess complexity by leaving that code mostly alone, and using the RTL assigned by it for partitions holding the initial versions of parameters.

    We could thus successfully remove the copyrename passes without harming generated code by integrating similar functionality into the out-of-SSA expander. It's not equivalent because we can now also coalesce versions of function arguments and return values with user-defined variables and
    compiler-introduced temporaries, which tends to generate slightly better code and to save compile time.

    We no longer create declarations for the temporaries: after some adjustments we made, GCC can now deal with the anonymous SSA names directly in the coalescer and in the expander, without an underlying
    declaration, completing the project that introduced anonymous SSA names years ago. This saves a bit of compile-time memory.

    We also added assertions to check that RTL assignments met the expectations with regards to register/memory placement and access modes. That revealed a number of cases in which results and parameters that we expected to hold in registers were assigned to memory, and of parameters and results in registers of unexpected modes. All of these cases were fixed, and the assertions remain active in development releases of GCC. This made the compiler more maintainable.

    The primary goal of this change was to make GCC more maintainable:  plenty of unnecessary or complex code was removed, and simpler code replaced it. Compile-time and even run-time benefits exist, but they
    were just desirable side effects.

    This improved out-of-SSA coalescer is expected to be present in the upcoming GCC release 6.

    Recent Posts

    • A case study in Kubelet regression in OpenShift

    • Profiling vLLM Inference Server with GPU acceleration on RHEL

    • Network performance in distributed training: Maximizing GPU utilization on OpenShift

    • Clang bytecode interpreter update

    • How Red Hat has redefined continuous performance testing

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Platforms

    • Red Hat AI
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue