Re: AVR: CC0 to CCmode conversion

[Paul Schlie <schlie at comcast dot net>]

> From: Richard Henderson <rth@redhat.com>
> On Sun, Mar 20, 2005 at 01:59:44PM +0300, Denis Chertykov wrote:
>> The reload will generate addhi3 and reload will have a problem with
>> two modified regs (ZCMP_FLAGS, CARRY_FLAGS) which will be a bad
>> surprise for reload. :( As I remember.
> 
> In order to expose the flags register before reload, you *must*
> have load, store, reg-reg move, and add operations that do not
> modify the flags.
> 
> Note, for instance, that i386 "add" instruction always modifies
> the flags, but the "lea" instruction does not.  So we emit the
> later when reload emits an add.
> 
> If you cannot meet these requirements, then you must represent
> "setcc" and "compare-and-branch" patterns as a single insn until
> after reload.  You can then split them apart, followed by peep2
> patterns to remove compare patterns that are redundant with
> immediately preceeding arithmetic.

- OK, so GCC's assumes that it may arbitrarily spill/reload at any
  point and not destructively modify the machines state; as opposed
  to attempting to select optimal points to do so through the analysis
  of the code's data-flow/control dependencies, and then as potentially
  may be necessary, re-synthesize machine state post the actions to
  consistently satisfy any dependencies which may remain.

- so in AVR's case, simply pretending that add operations don't modify
  CC state may only be asking for trouble; however may it be sufficient to
  somehow force spill/reload to only use indexed/auto-inc/dec load/store
  operations, without inadvertently picking up a general add/sub/etc.
  operation in the process which will modify CC state?