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

Li, Charles charles_li at playstation.sony.com
Thu Jul 2 15:55:12 PDT 2015

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

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>

More information about the llvm-dev mailing list