This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [PATCH] Go closures for s390[x]
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: rth at redhat dot com (Richard Henderson)
- Cc: libffi-discuss at sourceware dot org, Ulrich dot Weigand at de dot ibm dot com (Ulrich Weigand), krebbel at linux dot vnet dot ibm dot com (Andreas Krebbel)
- Date: Fri, 19 Dec 2014 15:48:40 +0100 (CET)
- Subject: Re: [PATCH] Go closures for s390[x]
- Authentication-results: sourceware.org; auth=none
Richard Henderson wrote:
> On 12/19/2014 07:13 AM, Ulrich Weigand wrote:
> > Actually, it sort-of is; the code does:
> > la %r14,0(%r13,%r9) # Set return address
> > br %r7 # ... and call function
> >
> > i.e. sets the return address register to point to one of the return stubs
> > and then jumps to the target function instead of calling it; so from the
> > point of view of an unwinder, it looks like the target function was called
> > from the instruction immediately preceding the return stub.
>
> Ah, good point. That's the sort of verbage that should be in the comment then.
>
> Is that optimization really worth it? Is there no call/return prediction stack
> to get confused? I know I replicated it in the code that I wrote, but really
> only now do I start to question it.
There's no call/return stack as such on current processors; we don't have
hard-coded call/return instructions, and the various OSes on the platform
use registers in quite different ways as part of their calling conventions.
However, I agree that in general it's probably best to avoid tricks like that.
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
Ulrich.Weigand@de.ibm.com