> From: Björn Haase <[EMAIL PROTECTED]> > I have the impression that you are trying to open open doors :-) : If IIUC > what Denis aims to do is to segment the re-organization of the back-end into > several independent small steps. One step will be the cc0 -> CC_mode issue he > is addressing now. The splitting issue would be one of the following steps. > One will have to verify this point, but it seems that only the splitting > issue requires accurate tracking of all the clobbers/settings of the > condition code. > > In my opinion segmenting the rework of the back-end would indeed be the best > approach, also because I expect that the instruction patterns *with* > splitting will be fairly different. E.g. I do not think that the "addsi3" > will be present any more. So it would be probably a lot of useless work to > add all of the clobbers for instruction patterns that are likely to vanish in > the near future.
Thank you, however I still don't understand the advantage of adopting an intermediate step which only seems to prohibit all forms of scheduling; and likely producing inferior code when multi-byte comparisons against 0 can't be peephole optimized away because the operation which may have produced equivalent side-effects doesn't happen to immediately sequentially precede it? Maybe I misunderstand the generality of the specified compare/if-then-else peephole optimizations? Are they guaranteed to match any opportunity to eliminate otherwise redundant a multi-byte comparison against 0, by forcing an exiting equivalent side-effect producing operation to be sequentially safely placed immediately preceding it's requirement (thereby effectively forcing an instruction ordering)? If this is the case, then my concerns are mostly satisfied; but still don't think its a good idea to hind side-effects, as although they may not be fully leveraged at the moment, hiding them would seem to only hurt, and never help in any circumstance. (But maybe I misunderstand the benefits of hiding them, are there any?)
