This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch i386]: Expand sibling-tail-calls via accumulator register
- From: Richard Henderson <rth at redhat dot com>
- To: Jeff Law <law at redhat dot com>, Kai Tietz <ktietz at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: "H.J. Lu" <hjl dot tools at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 27 May 2014 10:25:58 -0700
- Subject: Re: [patch i386]: Expand sibling-tail-calls via accumulator register
- Authentication-results: sourceware.org; auth=none
- References: <356718653 dot 5712706 dot 1400794422397 dot JavaMail dot zimbra at redhat dot com> <CAMe9rOrCiRSTA+4jiGeQLub4P--KX8XzkYiwAVWZUxzunhvkPQ at mail dot gmail dot com> <537F8DC7 dot 3090906 at redhat dot com> <777706000 dot 8424762 dot 1401128436051 dot JavaMail dot zimbra at redhat dot com> <20140526183208 dot GG10386 at tucnak dot redhat dot com> <1487116948 dot 8449887 dot 1401132170121 dot JavaMail dot zimbra at redhat dot com> <20140526193543 dot GH10386 at tucnak dot redhat dot com> <625132578 dot 8474723 dot 1401136339171 dot JavaMail dot zimbra at redhat dot com> <5384B1BB dot 4080000 at redhat dot com> <5384BBAD dot 5080606 at redhat dot com> <5384C1D8 dot 6080202 at redhat dot com>
On 05/27/2014 09:48 AM, Jeff Law wrote:
>> lea ofs(base, index, scale), %eax
>> ...
>> call *0(%eax)
>>
>> we might as well include the memory load
>>
>> mov ofs(base, index, scale), %eax
>> ...
>> call *%eax
> Ok. My misunderstanding.
>
> Granted, this probably doesn't happen enough to matter, but isn't it likely
> profitable from a pipeline standpoint to go ahead and do the memory load
> separate from the indirect call/jump as well?
I'm sure. Especially if the data is currently living in L2, and the scheduler
has enough room to move the load sufficiently early to hide the latency.
As I've said before, I think this is interesting solely as a space optimization.
r~