This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Status of m32c target?
> 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