[llvm-dev] RFC: code size reduction in X86 by replacing EVEX with VEX encoding

Hal Finkel via llvm-dev
2016-11-23T13:01:18Z

----- Original Message -----

> From: "Gadi via llvm-dev Haber" <llvm-dev at
lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Wednesday, November 23, 2016 5:50:42 AM
> Subject: [llvm-dev] RFC: code size reduction in X86 by replacing EVEX
> with VEX encoding

> Hi All.

> This is an RFC for a proposed target specific X86 optimization for
> reducing code size in the encoding of AVX-512 instructions when
> possible.

> When the AVX512F instruction set was introduced in X86 it included
> additional 32 registers of 512bit size each ZMM0 - ZMM31, as well as
> additional 16 XMM registers XMM16-XMM31 and 16 YMM registers
> YMM16-YMM31.
> In order to encode the new registers of 16-31 and the additional
> instructions, a new encoding prefix called EVEX , which extends the
> existing VEX encoding , was introduced as shown below:

> The EVEX encoding format:
> EVEX Opcode ModR/M [SIB] [Disp32] / [Disp8*N] [Immediate]
> # of bytes: 4 1 1 1 4 / 1 1

> The existing VEX encoding format:
> [VEX] OPCODE ModR/M [SIB] [DISP] [IMM]
> # of bytes: 0,2,3 1 1 0,1 0,1,2,4 0,1

> Note that the EVEX prefix requires 4 bytes whereas the VEX prefix can
> take only up to 3 bytes.
> Consequently, for the SKX architecture, many instructions that use
> only the lower registers of XMM0-XMM15 or YMM0-YMM15, can be encoded
> by either the EVEX or the VEX format. For such cases, using the VEX
> encoding results in a code size reduction of ~2 bytes even though it
> is compiled with the AVX512F/AVX512VL features enabled.

> For example: “vmovss %xmm0, 32(%rsp,%rax,4)“, has the following 2
> possible encodings:

> EVEX encoding (8 bytes long):
> 62 f1 7e 08 11 44 84 08 vmovss %xmm0, 32(%rsp,%rax,4)

> VEX encoding (6 bytes long):
> c5 fa 11 44 84 20 vmovss %xmm0, 32(%rsp,%rax,4)

> See reported Bugzilla bugs about this proposed optimization:
> https://llvm.org/bugs/show_bug.cgi?id=23376
> https://llvm.org/bugs/show_bug.cgi?id=29162

> The proposed optimization implementation is to add a table of all
> EVEX opcodes that can be encoded via VEX in a new header file placed
> under lib/Target/X86.
> A new pass is to be added at the pre-emit stage .
It might be better to have TableGen generate the mapping table for you instead
of manually making a table yourself. TableGen has a feature that is specifically
designed to make mapping tables like this. For examples, grep for InstrMapping
in:

lib/Target/Hexagon/Hexagon.td
lib/Target/Mips/MipsDSPInstrFormats.td
lib/Target/Mips/MipsInstrFormats.td
lib/Target/Mips/Mips32r6InstrFormats.td
lib/Target/PowerPC/PPC.td
lib/Target/AMDGPU/SIInstrInfo.td
lib/Target/AMDGPU/R600Instructions.td
lib/Target/SystemZ/SystemZInstrFormats.td
lib/Target/Lanai/LanaiInstrInfo.td

I've used this feature a few times in the PowerPC backend, and it's
quite convenient.

-Hal

> No need for special Opt flags, as it is always better to use the
> reduced VEX encoding when possible.

> Thank you for any comments or questions that you may have.

> Sincerely,

> Gadi.

> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--

Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161123/7af54779/attachment.html>