https://sourceware.org/bugzilla/show_bug.cgi?id=22871
--- Comment #9 from Linus Torvalds <torva...@linux-foundation.org> ---
I already pointed this out in email to hjl, but adding it to the bugzilla too,
in case people want to track it:
There are a few more common cases that can use the REX.W optimization, notably
movq $imm,%reg
and there it actually allows the whole unsigned 32-bit range, so it changes the
immediate logic a bit.
Right now gas generates a 10-byte instruction for
movq $0x87654321,%rax
in the form of
0: 48 b8 21 43 65 87 00 movabs $0x87654321,%rax
7: 00 00 00
but you can actually do it with just 5 bytes:
0: b8 21 43 65 87 mov $0x87654321,%eax
instead. Note that the C7/0 instruction with REX.W wasn't used,
because it sign-extends the 32-bit constant.
But even when the constant *isn't* in the full 32-bit range and you can use
C7/0 to avoid the long constant, gas currently picks a non-optimal instruction:
movq $0x77654321,%rax
becomes
0: 48 c7 c0 21 43 65 77 mov $0x77654321,%rax
which is 7 bytes, even though (again) that 5-byte 32-bit mov would
have sufficed:
0: b8 21 43 65 77 mov $0x77654321,%eax
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
