[LLVMdev] [x86] Compiling in 32-bit mode causes 64-bit asm source to be silently converted to its 32-bit equavilent

[Li, Charles]

Hi Craig,

I am Charles Li from Sony Playstation.

We are doing x86 code gen testing and, by chance, we noticed that compiling the 64-bit assembly instruction<https://msdn.microsoft.com/en-us/library/windows/hardware/ff561499(v=vs.85).aspx> "jrcxz" in 32-bit mode "-m32"
previously resulted in an error,
now gets silently converted into the 32-bit equivalent instruction "jecxz".
I have bisected this change in behavior down to r225075 - [X86] Make the instructions that use AdSize16/32/64 co-exist together without using mode predicates.<http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20141229/250681.html>
I am curious if this change in behavior was an intended feature or perhaps a side effect.


Here is my methodology.
The asm test case.
$ cat j64.s
        jrcxz   foo
foo:

Compiling the test case in 32-bit mode with Clang r225039.
$ r225039/clang.exe  j64.s -c -m32  -target x86_64-pc-linux-gnu
j64.s:1:9: error: instruction requires: 64-bit mode
        jrcxz   foo
        ^

Compiling the test case in 32-bit mode with Clang r225079 then disassembling the obj file to look for the jump instruction.
$ r225079/clang.exe  j64.s -c -m32  -target x86_64-pc-linux-gnu
(No Error)

$ objdump j64.o -d | grep j
j64.o:     file format elf32-i386
   0:   e3 00                   jecxz  2 <foo>

Just FYI, this is not blocking us in any way. I found this to be a very interesting discovery so I want to share it in the hopes of determining if it was intentional or not.

Sincerely,
Charles Li
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/ded0dad4/attachment.html>