On Sun, Mar 20, 2005 at 12:41:39PM -0500, Paul Schlie wrote: > - 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?)
Why ever would you get that idea that they're special? There's exactly one target that implements the "strmov" pattern, and that's i386. It either exposes the use of the flags register immediately (and so is seen by the optimizer), or it expands to a single instruction that implements the entire block copy, with no conditional loop. > - 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) You could enable the SMS pass, but it would only ever see the fused compare-and-branch pattern, and so would never be able to move the compare separately from the branch. You could enable more explicit compare elimination by creating even larger fused operate-compare-and-branch instructions that could be recognized by combine. I wouldn't actually recommend this though, because branch instructions with output reloads are EXTREMELY DIFFICULT to implement properly. It may be possible to enhance reload such that it inserts reloads on edges, and so removes the bulk of the pain from the backend, but it hardly seems worthwhile. r~
