[patch i386]: Expand sibling-tail-calls via accumulator register
Jeff Law
law@redhat.com
Tue May 27 16:48:00 GMT 2014
On 05/27/14 10:22, Richard Henderson wrote:
> On 05/27/2014 08:39 AM, Jeff Law wrote:
>> But the value we want may be sitting around in a convenient register (such as
>> r11). So if we force the sibcall to use %rax, then we have to generate a
>> copy. Yet if we have a constraint for the set of registers allowed here, then
>> we give the register allocator the opportunity to coalesce away the copies.
>
> We do have an existing call-clobbered register class that we currently do use
> for indirect sibcalls.
>
> The problem that Kai is trying to work around is that he doesn't want to load
> the value into a register, but its address. But the register allocator only
> has BASE_REG_CLASS and INDEX_REG_CLASS, and has no possibility to force the
> address components into registers that are call clobbered.
>
> My thinking is that, with few exceptions, this doesn't help anything. If we
> have to load the full address into a register:
>
> 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?
>
> As far as I can see, the only time we can actually save an instruction is when
> the address is fully symbolic:
>
> mov foo, %eax
> ...
> call *%eax
>
> becomes
>
> call *foo
Noted.
jeff
More information about the Gcc-patches
mailing list