This is the mail archive of the
libffi-discuss@sourceware.org
mailing list for the libffi project.
Re: [PATCH 3/8] sparc: Rewrite everything
- From: Richard Henderson <rth at twiddle dot net>
- To: David Miller <davem at davemloft dot net>
- Cc: libffi-discuss at sourceware dot org
- Date: Wed, 29 Oct 2014 13:44:37 -0700
- Subject: Re: [PATCH 3/8] sparc: Rewrite everything
- Authentication-results: sourceware.org; auth=none
- References: <1414525555-21256-4-git-send-email-rth at twiddle dot net> <20141029 dot 141027 dot 901195445453157818 dot davem at davemloft dot net> <545147A9 dot 9090401 at twiddle dot net> <20141029 dot 161058 dot 1101864756322678040 dot davem at davemloft dot net>
On 10/29/2014 01:10 PM, David Miller wrote:
> From: Richard Henderson <rth@twiddle.net>
> Date: Wed, 29 Oct 2014 13:01:45 -0700
>
>> On 10/29/2014 11:10 AM, David Miller wrote:
>>> Maybe I'm missing something?
>>
>> The two limits are in fact different. In gcc, see sparc_return_in_memory and
>> sparc_pass_by_reference.
>
> My bad, thanks for clarifying.
>
> That's the only thing that caught my eye. I think for most v9 chips a
> 'return' is slightly more expensive than a 'ret/restore'. 'return' is
> good for saving an instruction when you can put something in that
> delay slot, but if you can't then you might as well do 'ret/restore'.
Ah right, thanks.
The one other microarchitecture question I had was wrt call/ret paring.
I was assuming that, for predition purposes, "ret" vs "jmp" must be based on
the register used -- %i7 or %o7. Thus my call ... jmp %o7+const hopefully
keeps any call/return prediction stack in sync?
r~