[all-commits] [llvm/llvm-project] 3337f5: [X86] Fix handling of maskmovdqu in x32 differently

Harald van Dijk via All-commits all-commits at lists.llvm.org
Tue Apr 12 10:33:48 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 3337f50625a3e424a2d9a04c6034f6face81cca6
      https://github.com/llvm/llvm-project/commit/3337f50625a3e424a2d9a04c6034f6face81cca6
  Author: Harald van Dijk <harald at gigawatt.nl>
  Date:   2022-04-12 (Tue, 12 Apr 2022)

  Changed paths:
    M llvm/include/llvm/Support/X86DisassemblerDecoderCommon.h
    M llvm/lib/Target/X86/X86InstrSSE.td
    M llvm/lib/Target/X86/X86MCInstLower.cpp
    M llvm/lib/Target/X86/X86ScheduleBtVer2.td
    M llvm/utils/TableGen/X86DisassemblerTables.cpp
    M llvm/utils/TableGen/X86RecognizableInstr.cpp

  Log Message:
  -----------
  [X86] Fix handling of maskmovdqu in x32 differently

This reverts the functional changes of D103427 but keeps its tests, and
and reimplements the functionality by reusing the existing 32-bit
MASKMOVDQU and VMASKMOVDQU instructions as suggested by skan in review.
These instructions were previously predicated on Not64BitMode. This
reimplementation restores the disassembly of a class of instructions,
which will see a test added in followup patch D122449.

These instructions are in 64-bit mode special cased in
X86MCInstLower::Lower, because we use flags with one meaning for subtly
different things: we have an AdSize32 class which indicates both that
the instruction needs a 0x67 prefix and that the text form of the
instruction implies a 0x67 prefix. These instructions are special in
needing a 0x67 prefix but having a text form that does *not* imply a
0x67 prefix, so we encode this in MCInst as an instruction that has an
explicit address size override.

Note that originally VMASKMOVDQU64 was special cased to be excluded from
disassembly, as we cannot distinguish between VMASKMOVDQU and
VMASKMOVDQU64 and rely on the fact that these are indistinguishable, or
close enough to it, at the MCInst level that it does not matter which we
use. Because VMASKMOVDQU now receives special casing, even though it
does not make a difference in the current implementation, as a
precaution VMASKMOVDQU is excluded from disassembly rather than
VMASKMOVDQU64.

Reviewed By: RKSimon, skan

Differential Revision: https://reviews.llvm.org/D122540




More information about the All-commits mailing list