On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson <r...@redhat.com> wrote: > On 10/29/2011 05:41 AM, Peter Bigot wrote: >> It seems cc0 should probably still be preferred for CISC-style >> architectures like the MSP430. I'll give that approach a try. > > I think that's somewhat unfair. Take a close look at the RX and > mn10300 ports -- they're what I would call the most up-to-date > of the cisc-y ports.
Both RX and mn10300 may be cleaner architectures than MSP430, in that the machine descriptions only provide SI and DI versions of the insns. I admit I'm discouraged that it's necessary to have (1) an addsi3 insn, (2) an *addsi3_flags insn that differs from it only by adding a CC_REG set in the RTL template and a reload_completed condition, and (3) an addsi3_flags expander that replicates the RTL template of *addsi3_flags. For MSP430, the native operand sizes are QI, HI, and PSI, and I need all three, plus expanders for the derived SI and DI variants where gcc's ignorance of machine-dependent carry support causes the default expansions to be poor. The same sort of relationships between the instructions and the flags register exist for add, sub, ior, and, xor, and left and right shift operations. Even using iterators, this makes for an ugly machine description. The last straw for me is that adding CC_REG-related patterns into the RTL bleeds into the peephole definitions that I need to eliminate unnecessary (arguably wrong) register moves that get generated for RMW operations on memory-mapped peripherals. Those are already pretty hard to understand. Using CC_MODE in this case certainly appears much more complicated than using cc0. Do you believe the effort required to get it right would be justified? Where would the win come from? Peter
