diff options
author | Craig Topper <craig.topper@intel.com> | 2018-06-19 04:24:42 +0000 |
---|---|---|
committer | Craig Topper <craig.topper@intel.com> | 2018-06-19 04:24:42 +0000 |
commit | 0a5e90cc2a6d954ee0c2fae99e0f5d0cb82b3168 (patch) | |
tree | a52bf0d5614b75c98b4d48fc36ead5125c1bc266 /lldb/packages/Python/lldbsuite/support/sockutil.py | |
parent | 6e9b355cc9cd50da901a164f930fe1802b673969 (diff) | |
download | bcm5719-llvm-0a5e90cc2a6d954ee0c2fae99e0f5d0cb82b3168.tar.gz bcm5719-llvm-0a5e90cc2a6d954ee0c2fae99e0f5d0cb82b3168.zip |
[X86] Add a new VEX_WPrefix encoding to tag EVEX instruction that have VEX.W==1, but can be converted to their VEX equivalent that uses VEX.W==0.
EVEX makes heavy use of the VEX.W bit to indicate 64-bit element vs 32-bit elements. Many of the VEX instructions were split into 2 versions with different masking granularity.
The EVEX->VEX table generate can collapse the two versions if the VEX version uses is tagged as VEX_WIG. But if the VEX version is instead marked VEX.W==0 we can't combine them because we don't know if there is also a VEX version with VEX.W==1.
This patch adds a new VEX_W1X tag that indicates the EVEX instruction encodes with VEX.W==1, but is safe to convert to a VEX instruction with VEX.W==0.
This allows us to remove a bunch of manual EVEX->VEX table entries. We may want to look into splitting up the VEX_WPrefix field which would simplify the disassembler.
llvm-svn: 335017
Diffstat (limited to 'lldb/packages/Python/lldbsuite/support/sockutil.py')
0 files changed, 0 insertions, 0 deletions