Li, Charles
2015-Jul-02 22:55 UTC
[LLVMdev] [x86] Compiling in 32-bit mode causes 64-bit asm source to be silently converted to its 32-bit equavilent
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>
Craig Topper
2015-Jul-02 23:35 UTC
[LLVMdev] [x86] Compiling in 32-bit mode causes 64-bit asm source to be silently converted to its 32-bit equavilent
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 <charles_li at
playstation.sony.com> 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 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
>
--
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150702/670048f2/attachment.html>
Craig Topper
2015-Jul-04 00:01 UTC
[LLVMdev] [x86] Compiling in 32-bit mode causes 64-bit asm source to be silently converted to its 32-bit equavilent
Fixed in r241381 On Thu, Jul 2, 2015 at 4:35 PM, Craig Topper <craig.topper at gmail.com> 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 < > charles_li at playstation.sony.com> 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 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 >> > > > > -- > ~Craig >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150703/fb65ec26/attachment.html>