After synchronizing with Ian Lance Taylor on IRC, I'm in the process of implementing the cc0 replacement machinery he described here and found at <URL:http://gcc.gnu.org/wiki/general%20backend%20cleanup> after "Here is a possible approach in which macros are used in the MD file readers to avoid the pattern explosion". I understood noone else is working on this.
The approach is named CC_REG for brief (it's gated on a define_constant by that name). I haven't yet bumped into anything that need fundamental changes to the presented approach. The most important reason why I do this, is that I need the CRIS port to move away from the classic cc0-representation in order to include a subport (CRIS v32) which for performance needs scheduling for a modest single five-stage pipeline. IIUC patches have been presented for the DFA scheduler to support the cc0 machinery, but the patches were rejected as support being unwanted for cc0 machinery. The cc0 machinery has always been intrusive in the middle-end which is the main reason why it's no longer the preferred method for describing condition codes. The CC_REG approach seemed like a better approach than the brute-force approach used with the i386 port, mostly regarding port maintenance and pattern explosion in the .md file. What worries me most is that I'll not meet the Stage 1 end of the 25:th. This CC_REG machinery patches would arguably be affecting many files and as such be stage 1 material, but doesn't at all functionally affect any primary platform (all being non-cc0) or ports that still use the cc0 approach. The presented approach is recent and wasn't known until well into stage 1, so it couldn't be one of the "official" stage 1 projects. Still, I hope for an exception, assuming a patch is ready for review in about two weeks for inclusion in HEAD, to-be 4.1. brgds, H-P
