[PATCH] Correctly assemble unsized call instructions.

Jeff Muizelaar jmuizelaar at mozilla.com
Mon Jul 28 16:43:27 PDT 2014


================
Comment at: lib/Target/X86/AsmParser/X86Operand.h:213
@@ -211,3 +212,3 @@
   bool isMem16() const {
     return Kind == Memory && (!Mem.Size || Mem.Size == 16);
   }
----------------
Reid Kleckner wrote:
> Returning true for Size == 0 seems suspect to me.  What tests fail if we remove that clause?  My guess is that we start failing to match instructions like 'mov %eax, (%ebx)', because now isMem32 will return false for '(%ebx)'.
> 
> I think maybe the real fix is to remove this clause, and then add an 'isMemUnsized()' predicate, which the asm matcher uses to figure out memory operand sizes when the size is implied by the at&t size suffix (movll, movw) or the size of another operand (mov %eax, (%ebx)).
Correct. We start to fail to match mov eax, [ebx].

The asm matcher currently only looks at one operand at a time, from left to right so I'm not sure how we'd do the matching for something like mov [ebx], eax?

================
Comment at: test/MC/X86/intel-syntax-unsized-operand.s:11
@@ +10,2 @@
+call dword ptr [edx]
+call word ptr [edx]
----------------
Reid Kleckner wrote:
> What do we do for other instructions that take a single memory operand, like 'inc' and 'dec'?
Currently they probably end up as incw, decw. mov [eax], 1 ends up as mov word ptr [eax] 1. In MSVC they all become 'byte pointer' accesses, other assemblers including ml seem to reject them.

http://reviews.llvm.org/D4612






More information about the llvm-commits mailing list