RE: gcc and the IA64 ABI

["Winalski, Paul" <paul dot winalski at intel dot com>]

We are experimenting with taking advantage of non-default symbol
visibility (i.e., restricting symbol preemption) to enable more
aggressive optimizations, including dispensing with the caller
save/restore of gp on external calls made via undefined external
symbols with restricted (protected, hidden, or internal) visibility.
As permitted by the ELF Spec, we are interpreting a declaration such
as:

    void foo() __attribute__((visibility("protected")));

where foo is external to the current compilation unit, as an assertion
by the programmer that foo(), although external, will be linked into
the same component as the current compilation unit, and therefore
will share the same gp value, and therefore calls to foo() can dispense
with saving/restoring gp around the call.

The part of the IA64 ABI under discussion restricts tail calls to undefined
external symbols to those cases where the compiler knows that the
target of the tail call will be in the same component (and hence share
the same gp value) as the routine making the tail call.  Essentially
the same conditions as we are using for the optimization dispensing
with the save/restore of gp around a call.

Our study of the situation so far indicates that tail call opportunities
on Itanium are quite limited.  Use of the alloc instruction in the caller
precludes tail calls, for example.  But eliminating caller gp save/restore
seems to be promising.  Early testing seems to indicate significant
improvement on some important programs; we're still in the process of
collecting performance data.  If you have evidence that tail call
optimization is a significant performance win on Itanium, we'd love
to hear about it before we go charging down the wrong path.

Regards,

-Paul Winalski, Intel Corporation