This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch i386]: Expand sibling-tail-calls via accumulator register


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]