[PATCH] D14827: Adding support for missing variations of X86 string related instructions

[Sean Silva via llvm-commits]

silvas added a subscriber: silvas.
silvas added a comment.

In http://reviews.llvm.org/D14827#298742, @rnk wrote:

> Craig, can you give us a second opinion here?
>
> These string instructions need a memory operand size, but the encodings only support [esi]/[edi] as a memory operand. If the users asks for `ins byte ptr [eax], dx` and we assemble it to `ins byte ptr es:[edi], dx`, it seems highly likely that the user made a mistake.
>
> I'm trying to insist that we should either error or warn when the instruction that the user asked for is not encodable.


The intel manual even has a paragraph about this being misleading:

"""
At the assembly-code level, two forms of this instruction are allowed: the “explicit-operands” form and the “no- operands” form. The explicit-operands form (specified with the INS mnemonic) allows the source and destination operands to be specified explicitly. Here, the source operand must be “DX,” and the destination operand should be a symbol that indicates the size of the I/O port and the destination address. This explicit-operands form is provided to allow documentation; ***however, note that the documentation provided by this form can be misleading***. That is, the destination operand symbol must specify the correct type (size) of the operand (byte, word, or doubleword), but it does not have to specify the correct location. The location is always specified by the ES:(E)DI registers, which must be loaded correctly before the INS instruction is executed.

"""

(emphasis mine)


Repository:
  rL LLVM

http://reviews.llvm.org/D14827