Bug 834 - IA64: Change br to brl for "far" branches when possible
Summary: IA64: Change br to brl for "far" branches when possible
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.14
: P2 enhancement
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-08 04:21 UTC by John Worley
Modified: 2005-05-16 17:57 UTC (History)
1 user (show)

See Also:
Host: ia64-redhat-linux
Target: ia64-redhat-linux
Build: ia64-redhat-linux
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Worley 2005-04-08 04:21:58 UTC
This suggestion owes much to David Mosberger

Currently, when the loader detects that a branch symbol is beyond
the 16MB range of the 25-bit IP-relative branch (br), it adds a
trampoline bundle with a 64-bit IP-relative branch (brl). This
construct, however, is likely to incur a branch miss penalty.

However, for br.call, where a "far" branch is most likely, it has
been observed that the instruction preceeding the branch is frequently
a NOP. In this case, the bundle can be changed from (e.g):

{ .mib (or .mmb or .mbb)
   <any M-op>
   nop 0
   br<br completers> TargetSymbol
}

to the faster and more compact

{ .mlx
   <same M-op>
   brl<br completers> TargetSymbol
}

    If the previous instruction was not a NOP, then the trampoline
bundle can be appended as is currently done. The linker is already
looking at the code in this case (for the relocation), so it should
just be some straightforward logic added at that point.
Comment 1 John Worley 2005-04-08 16:56:33 UTC
One other note: GCC (at least) can issue a .bbb bundle where
the first two branches are NOPs. This case should be
converted to

{ .mlx
   nop
Comment 2 H.J. Lu 2005-05-12 16:12:38 UTC
A patch is postd at

http://sourceware.org/ml/binutils/2005-05/msg00428.html
Comment 3 H.J. Lu 2005-05-12 16:38:44 UTC
Slot 0 has to be NOP only for BBB. Here is an update.


http://sourceware.org/ml/binutils/2005-05/msg00431.html
Comment 4 H.J. Lu 2005-05-16 17:57:21 UTC
Fixed by

http://sourceware.org/ml/binutils/2005-05/msg00453.html