[Bug gas/25621] New: x86 jcc short/long is not relaxed to the finest.

[kaiyuan1 at andrew dot cmu.edu]

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.