> Yes, I know that CCmode can represent condition code. But just the fact > that it can represent it doesn't make it superior or cc0 inferior or > bad. Having different representations for the same thing has also its > obvious upsides (think of different representations in maths or > physics), and in the present case one has the choice between an explicit > RTL representation and an implicit (w.r.t. to RTL) one.
Different representations in maths are interesting only if you can easily go back and forth between them, so I don't think the analogy is valid here. > - cc0 does a good job and did always a good job in the past. In the > years I contributed to avr, there hasn't been a single cc0 flaw (all the > few, minor cc0-related issues were avr BE issues). cc0 does inhibit RTL optimizations because of the implementation constraints it imposes, most notably the non-separation of CC setters and users. > - No improvements of generated code are expected. avr won't benefit > from separating comparisons from branches (no scheduling). See above. Moreover, it is easy to implement a minimal form of scheduling to hide the latency of the loads (assuming some AVR processors are pipelined), in which case CCmode will give you a performance bonus. -- Eric Botcazou
