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