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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[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 instructionjrcxz” 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.

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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

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

Craig Topper
Forgot to copy llvmdev.

I think this part of the diff was a mistake. That Requires check still needs to be there.

   let Uses = [RCX] in
     def JRCXZ : Ii8PCRel<0xE3, RawFrm, (outs), (ins brtarget8:$dst),
-                           "jrcxz\t$dst", [], IIC_JCXZ>, AdSize64, Requires<[In64BitMode]>;
+                           "jrcxz\t$dst", [], IIC_JCXZ>, AdSize64;

I'll fix sometime this weekend.

On Thu, Jul 2, 2015 at 3:55 PM, Li, Charles <[hidden email]> wrote:

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 instructionjrcxz” 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.

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




--
~Craig

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

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

Craig Topper

Fixed in r241381


On Thu, Jul 2, 2015 at 4:35 PM, Craig Topper <[hidden email]> wrote:
Forgot to copy llvmdev.

I think this part of the diff was a mistake. That Requires check still needs to be there.

   let Uses = [RCX] in
     def JRCXZ : Ii8PCRel<0xE3, RawFrm, (outs), (ins brtarget8:$dst),
-                           "jrcxz\t$dst", [], IIC_JCXZ>, AdSize64, Requires<[In64BitMode]>;
+                           "jrcxz\t$dst", [], IIC_JCXZ>, AdSize64;

I'll fix sometime this weekend.

On Thu, Jul 2, 2015 at 3:55 PM, Li, Charles <[hidden email]> wrote:

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 instructionjrcxz” 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.

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




--
~Craig



--
~Craig

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev