> From: Paul Schlie <[EMAIL PROTECTED]> >> From: Richard Henderson <[EMAIL PROTECTED]> >> 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)
