Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 work consists of 4 subprojects:

  1. Basic ZICondops patterns in the RISC-V target description
    1. VRULL + Ventana + ESWIN
  2. Improvements to generate those patterns early in the RTL optimizer pipeline
    1. Ventana (primarily Raphael's work with bugfixing from Jeff) + ESWIN
  3. Fixes to cost model to enable more conditional move generatinon
  4. Improvements to the if-converter to consistently utilize the conditional zero primitive provided by ZICondops
    1. Mixed work from VRULL, Ventana & ESWIN

Evaluation of the initial implementation has indicated that idioms to implement 32 bit operations on rv64 are consistently not if-converted.  Improvements to capture those cases are in progressitem is meant to track pieces of the 2H2023 effort that did not get fully integrated upstream in time for gcc-14.


  • Use of ADD rather than IOR when possible


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: 1 FTE (Christoph Muellner and Philipp Tomsich) for initial developmentVentana: 1 FTE, ~12 wks.  Raphael Zinsly. Revamped basic support in preparation for upstreaming, support for conditional 32bit ops, conditional move support early in the compiler optimization pipeline

Ventana: Jeff Law.  Integration of Raphael's work with upcoming changes from Philipp.

Rivos: Oversight & review. 

SiFive: Oversight

External:

VRULL: Philipp Tomsich.  Initial work under contract to Rivos and Ventana.  Ongoing updates

ESWIN: Submission of basic Zicond support, conditional move and limited improvements to ifcvt

Jeff Law, Robin Dapp ESWIN: Fei Gao

External:


Dependencies



Status

Page Properties


Development

Status
colourGreen
titleCOMPLETEDCOMPLETE


Development Timeline2H20231H2024
Upstreaming

Status
colourBlueGreen
titleIN PROGRESS
(4 variants to reconcile)
COMPLETE



Upstream Version

gcc-14 15 (target)

(Spring 20242025)

gcc-13 RISC-V Coordination branch





Contacts

Philip Tomsich (VRULL)

Raphael Zinsly (Ventana)

Jeff Law (Ventana)


DependenciesNone



Updates

 

  • eswin has posted updates to the generic if-converter, both those and the version used by Ventana are breaking x86, this needs to be understood and fixed before this work can move forward

 

  • Cost model fixes integrated, resulting in more aggressive if-conversion and use of zicond
  • Additional testcases from ESWIN integrated
  • Leaves just the target independent changes to sort through

  • Testcases from patch #3 from eswin's kit are upstreamed
  • Patch which should fix the costing model issues enabling tests from patch #4 to get installed is ready for testing
  • No progress on patch #5 (target independent improvements to if-conversion)

 

  • One codegen fix and once ICE fix upstreamed
  • Addition of xventanacondops on top of zicond

 

  • Found and fixed missed case affecting CRC loop in coremark
  • Still untangling generic changes.  3 significant implementations in play
  • Cost model fixes still pending – critically important as we can't add the full suite of tests until that's fixed, hoping to wrap it up this week

 

  • Target dependent bits to wire up zicond to conditional move support done & integrated
  • Improvements to generic code to synthesize conditional arithmetic/logicals under review
    • ESWIN's code looks to be more aggressive in many respects (good)
    • But also less aggressive in handling sub-word cases
    • Not sure yet on approach to be taken
  • General upstream agreement that costing model needs work.
  • Dependencies on binutils/qemu dropped as they've been resolved.

 

  • Several bugs found & fixed in additional optimization patterns provided by ESWIN
  • Costing model issues are deeper than anticipated.  May spin out distinct project for that
  • Initial bits to wire up zicond to implement conditional moves ready to land

  • Basic Zicond support from ESWIN is the same as Ventana's internal bits and in-line with where VRULL was asked to go
    • Basic support integrated
    • Working on costing model which we ought to have sorted out 7/26.
  • Next will be unifying the ESWIN and Ventana bits to enable limited conditional move support using Zicond
  • After that we need to evaluate what if-converter bits are needed.

 

  • Slow movement here has resulted in a "competing" implementation.

 

  • Manolis from VRULL has started posting some of the generic work to facilitate use of Zicond/Xventanacondops
  • Jeff from Ventana continues to fix bugs in code which exposes Zicond/Xventanacondops to tree→RTL expansion code  (internal to Ventana right now, but definitely planned to upstream)

 

  • Binutils dependency has been resolved (Zicondops will appear in binutils-2.41 in July)
  • VRULL will repost their work.  Ventana will coordinate with VRULL on review/updates
  • Note QEMU dependency
  • Consistent reporting of stakeholders/partners

 

  • ZICondops binutils patch (re)approved

– Dates on or before June 15 are approximate

 

...

 

  • Items which were not completed in 1H2024 moved to new work item for 2H2024.

 

  • Robin has submitted a potential fix for detection of min/max in deepsjeng, which in turn should allow fixing the missed if-conversion in deepdjeng
  • Jeff has provided ESWIN with Ventana/code to handle sub-word objects.

 

  • 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.