[PATCH][AArch64] Tie operand 1 to operand 0 in AESMC pattern when AES/AESMC fusion is enabled

Kyrill Tkachov kyrylo.tkachov@foss.arm.com
Fri May 20 10:04:00 GMT 2016


Hi all,

The recent -frename-registers change exposed a deficiency in the way we fuse AESE/AESMC instruction
pairs in aarch64.

Basically we want to enforce:
     AESE Vn, _
     AESMC Vn, Vn

to enable the fusion, but regrename comes along and renames the output Vn register in AESMC to something
else, killing the fusion in the hardware.

The solution in this patch is to add an alternative that ties the input and output registers in the AESMC pattern
and enable that alternative when the fusion is enabled.

With this patch I've confirmed that the above preferred register sequence is kept even with -frename-registers
when tuning for a cpu that enables the fusion and that the chain is broken by regrename otherwise and have
seen the appropriate improvement in a proprietary benchmark (that I cannot name) that exercises this sequence.

Bootstrapped and tested on aarch64-none-linux-gnu.

Ok for trunk?

Thanks,
Kyrill

2016-05-20  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     * config/aarch64/aarch64.c (aarch64_fusion_enabled_p): New function.
     * config/aarch64/aarch64-protos.h (aarch64_fusion_enabled_p): Declare
     prototype.
     * config/aarch64/aarch64-simd.md (aarch64_crypto_aes<aesmc_op>v16qi):
     Add "=w,0" alternative.  Enable it when AES/AESMC fusion is enabled.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aarch64-fuse.patch
Type: text/x-patch
Size: 2625 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20160520/aeda5a5c/attachment.bin>


More information about the Gcc-patches mailing list