[PATCH][X86] AVX512: Disassembler support for compressed displacement

Adam Nemet anemet at apple.com
Tue Jul 15 17:04:07 PDT 2014


Hi,

I am copying a few people directly to make sure this does not get lost among the other AVX512 patches.  There are some design decisions I making here that people may be interested reviewing.

Currently there is no support for compressed displacement (cdisp8) in the disassembler so we effectively print the wrong (unscaled) displacement value.  The fact that an instruction uses cdisp8 and which form of it is an attribute of the *instruction* rather than the operand.  This fact and the parameters of cdisp8 are specified by deriving an instruction definition from the EVEX_CD8<> class.

As a consequence when we decode the displacement we decode it according to ENCODE_RM.  This is the encoding type for the operands covered by ModRM.  ENCODING_RM is derived from the type of the operand, e.g. i128mem in i128mem:$src2.  A table is generated by the X86-specific code in tablegen.  It specifies for each operand of each instruction the encoding type and the operand type.

My approach is to modify the X86 code in tablegen code to consult the instruction attributes *in addition* to the operand type to determine the encoding type.  Thus for example instead of ENCODE_RM, VADDPSZrm will have ENCODE_RM_CD64.  The meaning is that when decoding the displacement, a scale of 64 should be applied to it.

There is another layering twist to this.  The TD interface to EVEX_CD8 is nice and flexible so there are 32 possible combinations of values for EVEX_CD8<>.  Luckily these all translate into 7 different scaling values.  So clearly to avoid bloating up the encoding type enum we want to include the resulting scaling values in the encoding type rather than the current cdisp8 instruction attributes from TD.

The assembler (isCDisp8) already has code to compute the cdisp8 scaling value from the attributes.  So we would need to share code between the assembler and tablegen.  I don’t think there is precedence for this but as it turns out it’s not too involved to formulate the logic to compute the scaling factor in TD.  That way both the assembler and the tablegen can use the readily computed value.  Tablegen can use it then to adjust the encoding type from ENCODE_RM to ENCODE_RM_CD<n>.  

TD needed a limited form of the logical left and right shift operators.  I implemented these with the bit-extract/insert operator (i.e. blah{bits}).

My approach with the patches was to go incremental in order to convince myself that the TD code is in fact equivalent to the original C++ code.

Please let me know if this looks OK.

Adam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-X86-AVX512-Move-compressed-displacement-logic-to-TD.patch
Type: application/octet-stream
Size: 5938 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140715/993998ba/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-X86-AVX512-Use-the-TD-version-of-CD8_Scale-in-the-as.patch
Type: application/octet-stream
Size: 6693 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140715/993998ba/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-X86-AVX512-Rename-EVEX_CD8V-to-CD8_Form.patch
Type: application/octet-stream
Size: 2482 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140715/993998ba/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-X86-AVX512-Add-disassembler-support-for-compressed-d.patch
Type: application/octet-stream
Size: 8783 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140715/993998ba/attachment-0003.obj>


More information about the llvm-commits mailing list