This is the mail archive of the
mailing list for the GCC project.
Re: Static Chain Register on iOS AArch64
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>, Stephen Cross <scross at scross dot co dot uk>, gcc at gcc dot gnu dot org
- Date: Mon, 08 Jun 2015 10:18:45 -0700
- Subject: Re: Static Chain Register on iOS AArch64
- Authentication-results: sourceware.org; auth=none
- References: <CADC9Eqps-Y5=7jBMsuGO7wd-U7QH2M4NUUZmGgZ89p5X5D_jjQ at mail dot gmail dot com> <55702B1F dot 9040707 at foss dot arm dot com> <5571C66A dot 3060100 at redhat dot com> <5572F4A7 dot 7040908 at foss dot arm dot com> <5575C9A6 dot 3030706 at redhat dot com> <5575CA10 dot 1070402 at foss dot arm dot com>
On 06/08/2015 10:00 AM, Richard Earnshaw wrote:
r12 can *also* be clobbered by interworking calls or calls that span
more than the branch range of a call instruction. Rare, but possible.
I can only presume from this that nested functions are not reliable now, for
very large programs. Unless you somehow force the nested function to be within
N bytes of the parent function. A direct call to a static function, but with a
static chain to its parent frame.
That said, most go closures are already called indirectly. It's rare, but
possible, for optimization to see through the construction of a closure and
produce a direct call.
It ought to be possible to modify the aarch32 backend to force a call to be
indirect, and thus not be subject to branch islands, whenever the
SYMBOL_REF_DECL has DECL_STATIC_CHAIN set?