https://sourceware.org/bugzilla/show_bug.cgi?id=25621
Bug ID: 25621
Summary: x86 jcc short/long is not relaxed to the finest.
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gas
Assignee: unassigned at sourceware dot org
Reporter: kaiyuan1 at andrew dot cmu.edu
Target Milestone: ---
Created attachment 12335
--> https://sourceware.org/bugzilla/attachment.cgi?id=12335&action=edit
The source assembly and generated lst files.
The example is in the attachment.
The lst file was generated using:
`as --32 -almns=oggenc.lst oggenc.s -o /dev/null`
Here is a fragment of instructions from oggenc.lst:
###
109319 2b975 0F8E8D00 jle .LBB268_16
109319 0000
...
109330 2b984 8DB42600 .align 16, 0x90
109330 0000008D
109330 74260090
...
109428 .LBB268_16: #
%.preheader.preheader
109429 # in Loop:
Header=BB268_11 Depth=2
109430 2ba08 8B4DC0 movl -64(%ebp), %ecx # 4-byte Reload
###
In this case, "109319 jle" used a long jcc encoding because the distance is in
0x8D offset.
However, I think that this case can fit into a short jcc:
If we assume that we can use a short jcc encoding, "2b975 jle" will use 2 bytes
instead of 6 bytes.
Then, "2b984 .align" will actually start at "2b980" because of the 4 bytes
saved by a short jcc.
Since "2b980" is already 16 bytes aligned, the alignment is no longer
necessary, and there is another 12 bytes saved.
Now, the "2b975 jle" jump distance becomes "0x8D - 0x4 - 0xC = 0x7D" offsets,
which can be fit into a short jcc.
--
You are receiving this mail because:
You are on the CC list for the bug.
