Yes, the CC registers should both not be a single logical register (I don't think they ever were in x86? can't remember for sure) to avoid false dependencies between unrelated sets of bits, and they shouldn't be a single physical register and should be renamed.
I see what you're saying about having different pools of registers for different purposes, instead of having to put everything into either the int, float, or control pool. I had ideas about generalizing the register interface a long time ago where there would be a generic idea of a register file and then the quantity of each flavor (int, float, misc) would be variable. That would make some things like indexing into different sets of floating point registers (x87 vs MMX vs XMM vs whatever) easier since you wouldn't have to apply a base offset, and would let you rename them in different pools. I think that might be worth reviving if I ever find the time to dive in and fill out the design and do the surgery that would require, but that would let us have ccregs and vector regs and whatever else regs without the extra bulk in all the interfaces and iterations of those interfaces that pass registers around, and avoid the preprocessor a little bit more. Gabe On Wed, Oct 17, 2018 at 6:43 AM Andreas Sandberg <[email protected]> wrote: > Hi Gabe, > > If I remember correctly, we switched from int regs to cc regs in the > Arm ISA back in 2014 for the same reason as AMD. I.e., to get a separate > register pool in the O3 CPU when renaming. We have similar renaming > issues issues for vector registers, which is why we introduced the new > vector register class a while back. > > Cheers, > Andreas > > On 17/10/2018 00:33, Beckmann, Brad wrote: > > +Yasuko > > > > Hi Gabe, > > > > Yes, I remember that change. That was actually performed by a former > AMD co-op Binh Pham (who was advised by Yasuko). Bihn did a lot of great > work digging into the O3 model finding various performance bugs. Most of > his fixes where added back in 2015, but some of them never got checked in > (e.g. splitting store access requests from store data requests). > > > > CC register renaming was a big performance issue with x86. By mapping > all CC regs to one physical renamed register added a lot of false > dependencies. It is very important that they stay separate. > > > > I hope that helps. > > > > Brad > > > > > > > > -----Original Message----- > > From: gem5-dev <[email protected]> On Behalf Of Jason Lowe-Power > > Sent: Tuesday, October 16, 2018 3:10 PM > > To: gem5 Developer List <[email protected]> > > Subject: Re: [gem5-dev] cc registers > > > > Hey Gabe, > > > > I don't know if this helps, but I remember a lot of problems with > register renaming and CC registers ~6ish years ago. IIRC, there's a > separate pool of physical registers for the CC registers so that they do > not limit the renaming of "normal" registers. > > > > There were probably some discussions on the former reviewboard about > this. > > But again, it was so long ago that I don't remember the exact context. > In fact, this might not have anything to do with why they are special > registers. > > > > Cheers, > > Jason > > > > On Mon, Oct 15, 2018 at 8:57 PM Gabe Black <[email protected]> wrote: > > > >> Hey folks. I think I'm missing some context from when I was away from > gem5. > >> Does anyone know why there's a separate register file defined > >> explicitly for condition code registers? Why is having them as integer > >> registers not sufficient? > >> > >> Also as a general point, it's bad form to have "generic" features like > >> this which are hidden behind #ifdefs and #defines and only implemented > >> for one or two ISAs. Another example of this is a feature in MIPS > >> which it uses to read registers of other threads and which is only > >> available in that ISA. If the primitives available for ISAs aren't > >> sufficient lets fix that, not add on ISA specific extensions which are > >> unused or incompatible with most of the ISAs and hidden behind flags. > >> > >> Gabe > >> _______________________________________________ > >> gem5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
