Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 172035 - save 2 bytes for "movq $0x38,%rax"
save 2 bytes for "movq $0x38,%rax"
Product: Fedora
Classification: Fedora
Component: binutils (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2005-10-29 13:23 EDT by John Reiser
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-29 13:52:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Reiser 2005-10-29 13:23:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
The current generated code for "movq $0x38,%rax" is 7 bytes: 0x48,0xc7,0xc0,0x38,0,0,0.  Instead: 0xb8,0x38,0,0,0 is only 5 bytes, achieves exactly the same effects (value in %rax, and no change in condition codes [flag register]), and executes just as quickly.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Compare these variants:
_start: .globl _start
        nop; int3
        movq $0x38,%rax
        movl $0x39,%ecx
        movq $-0x38,%rdx
        movl $-0x39,%ebx
        nop; nop
$ gcc -o foo -nostartfiles -nostdlib foo.S
$ gdb foo
x/i $pc
x/2x $pc
p $rax
x/i $pc
x/2x $pc
p $rcx
x/i $pc
x/2x $pc
p $rdx
x/i $pc
x/2x $pc
p $rbx


Actual Results:  (gdb) x/i $pc
0x4000b2 <_start+2>:    mov    $0x38,%rax
(gdb) x/2x $pc
0x4000b2 <_start+2>:    0x38c0c748     0xb9000000
(gdb) stepi
0x00000000004000b9 in _start ()   ## instruction was 7 bytes
(gdb) p $rax
$1 = 0x38

(gdb) x/i $pc
0x4000b9 <_start+9>:    mov    $0x39,%ecx
(gdb) x/2x $pc
0x4000b9 <_start+9>:    0x000039b9      0xc2c74800
(gdb) stepi
0x00000000004000be in _start ()   ## instruction was 5 bytes
(gdb) p $rcx
$2 = 0x39

(gdb) x/i $pc
0x4000be <_start+14>:   mov    $0xffffffffffffffc8,%rdx
(gdb) x/2x $pc
0x4000b2 <_start+2>:    0x38c0c748      0xb9000000
(gdb) stepi
0x00000000004000c5 in _start ()   ## instruction was 7 bytes
(gdb) p $rdx
$3 = 0xffffffffffffffc8

(gdb) x/i $pc
0x4000c5 <_start+21>:   mov    $0xffffffc7,%ebx
(gdb) x/2x $pc
0x4000c5 <_start+21>:   0xffffc7bb      0x009090ff
(gdb) stepi
0x00000000004000ca in _start ()   ## instruction was 5 bytes
(gdb) p $rbx
$4 = 0xffffffc7

Expected Results:  The assembler should have chosen the 5-byte sequence "0xb8,0x38,0,0,0" for "movq $0x38,%rax" instead of the 7-byte sequence "0x48,0xc7,0xc0,0x38,0,0,0".

Additional info:
Comment 1 Jakub Jelinek 2005-10-29 13:52:14 EDT
When you want that, just write movl $0x38, %eax instead.
GCC does exactly that.

movq in x86_64 assembler is not "some instruction to move source to destination",
but a particular instruction, it would be very bad idea to do something
else, as code might e.g. rely on the instruction size.

Note You need to log in before you can comment on or make changes to this bug.