MODE_CC migration experience on h8300 port

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi,

I finished converting h8300 port to MODE_CC.

Here are some notes.

o No new testsuite failures.

o Currently, 0.15% code size increase on real-world testcases.  (H8
  does not need scheduling, so code size roughly equals speed.)

o Took me about one part-time week.

o Added (clobber (reg:CC CC_REG)) to every pattern except compare
  instructions, where CC_REG is the condition code register.

o I followed the same style as i386 or s390, including the
  match_cc_mode trick, saving compare operands in global variables,
  arithmetic-and-compare combined insns, etc.

o Added Ian's TARGET_CC_MODES_COMPATIBLE.  It works!

o Improved move2add to deal with single_set instead of strictly SET
  only patterns.

o If I introduce an arithmetic insn that neither modifies or uses
  CC_REG, I get a reload failure.  I am guessing this is because there
  are no move instructions that do not clobber CC_REG.  As long as
  every instruction either uses or clobbers CC_REG, this should be OK
  because the middle-end is effectively forced to put a CC_REG setter
  immediately before a CC_REG user, but this is like a time bomb.

o I'm not sure if I should check in this thing because...

  Cons:
    o a little messy because of a whole bunch of parallels

    o the reload failure thing mentioned above

  Pros:
    o I don't have to cry when somebody breaks cc0 stuff

    o I can precisely describe which bits of CC_REG I use, allowing a
      safe conditional move, exotic condition set, etc.

    o compare instructions at the beginning of a basic block following
      a barrier can be removed thanks to Ian's reundant compare
      optimization, whereas the equivalent optimization in the cc0 has
      been disabled.  (Look for "if (0" in final.c.)

o I haven't tried Zack's idea: I could have a compare-and-branch
  instruction without using cc0 or MODE_CC until final or so and then
  splites the branch into compare and branch.  This way, I could avoid
  massive parallels, but hen I don't know a clean way of removing
  redundant compares at the end.  (To be preceise, Zack's idea was to
  keep compare-and-branch insns until after reload.  Anyway, in
  general, more deviation rtl has from actual assembly instructions,
  more extra machinery is needed to fix up things.)

Any thoughts?

Kazu Hirata