Hi folks, Thinking more about Yasuko's problem where performance is going down because of increased physical register pressure due to the split CC register, it occurs to me that in the end we'll almost certainly need to specialize the renaming mechanism to deal with condition codes anyway. That is, no rational x86 implementation would take up an entire physical GPR just to hold a few bits that probably aren't going to be read anyway.
The more "conventional" solution is described here: http://www.ptlsim.org/Documentation/html/node7.html#SECTION02540000000000000000 Basically every physical GPR includes a set of (possibly invalid) CC bits. The various CC sub-fields have to be renamed separately, as the producer of a particular CC field may not be the latest producer of any particular GPR value, but the CC subfield rename registers will always point to a physical register file entry. I realize this is not a trivial change to the O3 model, but I think it's one that needs to be made. I'm bringing it up now because it may (probably will) impact how we handle the partial CC read/write issue that's still outstanding. To me there's no sense in fixing the CC problem in the current renaming context, particularly since there are no easy solutions. We're probably better off revamping how CC renaming works to begin with, then try and optimize that solution to deal with partial writes. For example, in the CC renaming model I'm envisioning, having bitmasks of which CC subfields get read or written by a particular micro-op might be adequate, and it would be much easier to generate bitmasks like this on the fly than it would to do the dynamic munging of source register indices that we've been talking about. Thoughts? Steve PS: In my search for a reference on CC renaming, I ran across the following paper that appears to have a nice summary of x86 instructions and their impact on flags. I don't know if it's relevant or not, but I thought I'd include the link in case it's helpful: http://hpc.aut.uah.es/informes/TR-UAH-AUT-GAP-2006-23-en.pdf (see Section 4 on pp. 5-6) _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
