/
CT_00_042 -- Additional Constant Synthesis Improvements

CT_00_042 -- Additional Constant Synthesis Improvements

Constant synthesis was greatly improved during 2024.  The areas noted here are exploratory and thus some ideas may be useful, some may not. 


Areas to explore:

  1. When possible derive the upper and lower halves from a common sequence, so for example sharing a lui
    1. Can this be handled during synthesis?
    2. May also be capturable during reload_move2add, but hard register dependencies may get in the way
  2. Reevaluate the mvconst_internal pattern
    1. Natural tension between exposing the synthesis early vs late. 
    2. Exposing early makes synthesis instructions optimizable, but leads to longer, more complex sequences which may inhibit optimization in some cases
      1. Combine in particular is sensitive to these issues as it has limits on the number of instructions to process at a time
      2. Synthesis counts against those limits (and-shift32.c is a great example)
    3. Exposing late leads to an inability to optimize the synthesis itself.  dup-{1,2,3} are a good example
    4. No good solutions
      1. General desire to move away from the mvconst_internal pattern
      2. Limiting constants handled by that pattern should generally be OK direction-wise as long as we don't regress code generation
      3. Combine needs improvement in its handling of REG_EQUAL notes.  Right now they're only used for 2→1 cases, but we need them across the board.
        1. Refactor the relevant code
        2. Consider staging in the improvements
        3. Pay particular attention to note distribution which can be quite hairy
      4. Local constant propagation after combine
        1. Constant propagator only supposed to work with cfglayout mode
        2. Perhaps not allow changing JUMP_INSNs would allow it to properly work outside cfglayout mode?
      5. reload_cse_move2add
        1. Limited in its scope due to hard register dependencies.
        2. Perhaps utilize REG_EQUAL notes and handle common cases for depedencies?
      6. vsetvl optimization
        1. Also limited by hard register dependencies, particularly for 2**n constants that don't fit into immediate field
        2. Ideally if we come up with a solution for reload_cse_move2add we could do something similar here?
        3. Is it worth the effort?
  3. Partially redundant constants
    1. Some paths compute the constant more than once, while some paths not at all
    2. Thus poor fit for PRE
    3. If register pressure is low, then it may be profitable to speculatively hoist more aggressively


Stakeholders/Partners

RISE:

Ventana: Jeff Law & Raphael Zinsly – general oversight / guidance and implementation work.

Rivos: Vineet Gupta – generally interested in constant synthesis and has some state on #5 above.

External:



Dependencies



Status

Development

EXPLORATION


Development Timeline1H2025
Upstreaming

NOT STARTED



Upstream Version

gcc-16 (target)

(Spring 2026)





Contacts

Jeff Law (Ventana)


DependenciesNone


Updates

 

  • Items not likely to land in 2H 2024 moved out into new item for 2025

Related content

CT_00_010 - Improve Long branch/jump support (GCC)
CT_00_010 - Improve Long branch/jump support (GCC)
Read with this
CT_00_031 -- Additional Constant Synthesis Improvements
CT_00_031 -- Additional Constant Synthesis Improvements
More like this
2025-1H - Compilers and Toolchains Priorities
2025-1H - Compilers and Toolchains Priorities
Read with this
CT_00_029 -- Improve constant synthesis
CT_00_029 -- Improve constant synthesis
More like this
CT_00_027 -- Improve ceil/round code generation in GCC
CT_00_027 -- Improve ceil/round code generation in GCC
More like this
CT_00_028 -- Investigate and improve Scalar code generation for cactuBSSN
CT_00_028 -- Investigate and improve Scalar code generation for cactuBSSN
More like this