Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

About

The ZiCondops extension provides a conditional zero primitive upon which subsets of conditional move and conditional arithmetic/logical operations can be implemented.   Transforming control flow into conditional operations can improve code performance by eliminating branch mispredict costs as well as reducing the load on the branch predictors.  The earlier in the optimizer pipeline these transformations are performed the more likely they are to expose secondary optimization opportunities as well since the transformations result in larger basic blocks (a fundamental unit of code most compiler optimizations work on).


This item is meant to track pieces of the 2H2023 effort that did not get fully integrated upstream in time for gcc-14.


  • Improvement of if-conversion pass in GCC to handle SUBREG and zero/sign extended objects.
  • Use of ADD rather than IOR when possible
  • If-convert the conditional in the move_one_fast loop of deepsjeng
    • Two approaches
      • Improve min/max discovery in gimple which should simplify the conditional code to optimizable form in the RTL if-converter code
      • Improve the RTL if-converter code to better handle multiple if-convertable instrutions


Analysis has shown that the most common missed if-conversion cases for RISC-V are related to mode changing operators such as SUBREG, ZERO_EXTEND and SIGN_EXTEND which are commonly used when operating on 32bit objects for rv64..  ESWIN and Ventana have differing implementations in this space that need to be resolved.  The core concern with the ESWIN implementation is that it directly modifies the objects in the IL, which in turn means that it's difficult (potentially impossible) to correctly handle certain cases (shifts).  In contrast the Ventana implementation emits new IL for the converted sequence and deletes the old parts of the IL.


WRT ADD vs IOR.  When there are no bits in common between the two input operands, ADD and IOR are equivalent from a functional standpoint.  ADD should be slightly preferred over IOR because ADD has a higher likelihood of being implemented as a compressed instruction when compared to IOR (IOR only allows a subset of the register file to be used in compressed forms).


Stakeholders/Partners

RISE:

Ventana: Raphael Zinsly, Jeff Law

External:

ESWIN: Fei Gao

Dependencies



Status

Development

IN PROGRESS


Development Timeline1H2024
Upstreaming

IN PROGRESS



Upstream Version

gcc-15 (target)

(Spring 2025)





Contacts

Raphael Zinsly (Ventana)

Jeff Law (Ventana)


DependenciesNone


Updates

 

  • ESWIN has upstreamed their change to use ADD rather than IOR for generalized conditional moves.  While technically not allowed at this stage of the gcc-14 cycle, it was approved as an exception given how safe it should be.
  • Ventana is de-emphasizing extension and subword cases.  We'd be happy to provide the work-in-progress to ESWIN or anyone else that wants to try and further improve if-conversion to handle those cases.

 

  • Ventana has an internal adjustment to the generalized conditional move code to use ADD rather than IOR.  It will be submitted upstream as soon as gcc-15 is open for development.
  • Ventana also has proof of concept code for the deepsjeng issue

 

  • Remaining items from 2H2023 pulled into H12024 project.
  • No labels