[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