Re: AVR: CC0 to CCmode conversion

[Paul Schlie <schlie at comcast dot net>]

> From: Paul Schlie <schlie@comcast.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.
> 
> - 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?

- what about blk moves? (as they would seem to most likely destructively
  modify the machine's cc state in most implementations, as their
  implementation implies a conditional loop; or are they an exception?
  if so, why?)

>> 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.

- what would be the requirements to enable the SMS pass (assuming it
  to be the most likely appropriate) to try to reorder operations such
  that a naturally occurring operation with the required side effects
  for a conditional branch may be moved closer to to it, such that an
  otherwise explicit compare may be optimally eliminated? (as opposed
  to an otherwise more coincidental peephole opportunity)