Thanks for your contribution.
In general, I’d say that these instructions tend to capture common patterns
that could map well to a “fast-path” implementation.
Cracking them in a conservative way might end up jeopardising their goal, as
more aggressive implementations could be possible, so I’d recommend to leave
the default “vanilla” implementation as it is and avoid cracking.
The other option could be to include your changes as a decoder flavour - see
commit d3d15974 - and leave the non-cracked version as default choice.
On 14/10/2016, 14:26, "gem5-dev on behalf of Fernando Endo"
<gem5-dev-boun...@gem5.org on behalf of fernando.en...@gmail.com> wrote:
>I'd like to know if the following patch may interest the community.
>I split conditionally executed AArch64 instructions into two or three uops,
>in order to use at most 3 register file ports, instead of 4 in the current
>code. The vast majority if not all AArch64 uops use up to 3 RF ports.
>CSEL (and similarly CSINC, CSINV, CSNEG FCSEL) are split as follows:
>CSEL Rd, Rn, Rm, cond
>uop 1: (cond) ? Tmp0 = Rn : 0
>uop 2: (!cond) ? Tmp1 = Rm : 0
>uop 3: Rd = Tmp0 + Tmp1
>CCMN (and similarly CCMP, FCCMP) are split as:
>CCMP Rn, Rm, #imm, cond
>uop 1: Tmp_nzcv = CMP Rn, Rm
>uop 2: (cond) ? nzcv = Tmp_nzcv : #imm
>Just asking because the patch works in my branch, I didn't rebase/test over
>Fernando A. Endo, Post-doc
>INRIA Rennes-Bretagne Atlantique
>gem5-dev mailing list
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