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 <gem5-dev-boun...@gem5.org> On Behalf Of Jason Lowe-Power
Sent: Tuesday, October 16, 2018 3:10 PM
To: gem5 Developer List <gem5-dev@gem5.org>
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 <gabebl...@google.com> 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
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
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
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to