> From: Paul Koning <[EMAIL PROTECTED]> >> "tm" == tm gccmail <[EMAIL PROTECTED]> writes: >>> On 25 Mar 2005, Ian Lance Taylor wrote: >>> Safe but very costly. It assumes that every processor has a cheap >>> way to save and restore the condition codes in user mode, which is >>> not necessarily the case. And it assumes that the save and restore >>> can be removed when not required, which is not obvious to me. >> >> tm> Not necessarily. >> >> tm> You need the ability to regenerate the condition code. There's at >> tm> least two ways of doing this: >> >> tm> 1. Saving/restoring the condition code >> >> tm> 2. Rematerializing the condition code. This would usually be a >> tm> simple load which is faster than the save/load combo of #1. > > "is faster" -- on some processors, yes. Not on all. For example, an > MFPS/MTPS pair to a register on a PDP-11 (when available) is likely to > be faster than a load that references memory.
Agreed, from the best I can tell in general, if a target's status code register has live dependants upon a destructive spill/restore, it seems almost always preferable to save/restore it temporarily either to a local register, or secondarily likely to the stack; as although it may be simpler in some instances to regenerate it, this is only reasonably possible if the source datum which the status code itself represents is intact, and is further complicated by the fact that some codes such as carry or overflow are much harder to reliably recreate it without literally having to track and re-compute the sequence which produced them, which in general is both difficult and likely expensive. (Therefore save/restoring the status around destructive spill/restores seems like the simplest general solution, and hopefully being required infrequently enough to have insignificant impact.) (but acknowledge that it's dependant on relatively infrequent need to do so by exposing and tracking the status register's dependants thereby enabling conditional save/restore, and correspondingly ideally attempting to position spill/reloads at points where the status register naturally has no dependants, thereby further helping eliminate it's otherwise necessity)
