This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [PATCH 0/4] s390 improvements
- From: Richard Henderson <rth at redhat dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, libffi-discuss at sourceware dot org, Ulrich dot Weigand at de dot ibm dot com, vogt at linux dot vnet dot ibm dot com, krebbel at linux dot vnet dot ibm dot com
- Date: Fri, 19 Dec 2014 10:37:29 -0600
- Subject: Re: [PATCH 0/4] s390 improvements
- Authentication-results: sourceware.org; auth=none
- References: <201412191614 dot sBJGEwd3013748 at d03av02 dot boulder dot ibm dot com>
On 12/19/2014 10:14 AM, Ulrich Weigand wrote:
> In the end, it's probably OK for low-level code like libffi to make certain
> assumptions on the behavior of the toolchain. I'm not quite sure whether
> this actually gets us any significant benefit in this case. Does it really
> matter whether ffi_prep_args is called from ffi_call_int vs. ffi_call_SYSV?
I think it's the indirect call back to ffi_prep_args that I find ugliest,
and for most targets, totally unnecessary.
>> It's true that the load of %r15 is now a nop. It hadn't been at one point in
>> my development; ffi_prep_args had had more than 5 parameters, and so there was
>> extra stack allocated. I suppose if ffi_prep_args were inlined, one could be
>> certain of this (since there will be no function calls) and document it as such.
>
> If we do use such tricks, this version may actually be preferable.
I'll post that version shortly. If you still don't like it, then I'll
try another tack whereby we simply avoid the indirect call.
r~