Alexander Monakov <amona...@ispras.ru> wrote:
On Fri, 23 Apr 2021, Josh Haberman via Gcc wrote:
On Fri, Apr 23, 2021 at 1:10 PM Iain Sandoe <idsan...@googlemail.com>
wrote:
I did try to use it this ^ for GCC coroutines (where such a guarantee is
pretty important)
However, the issue there is that not all targets support indirect
tailcalls.
I'm not familiar with this limitation. What targets do not support
indirect tail calls?
On Power64 tailcalls to anything that is not a static function are
tricky, and
current Clang ICEs for musttail indirect calls (or direct calls to a
function
which is not static) on that target. GCC also doesn't do indirect
tailcalls on
Power64.
Also, NVPTX (being an intermediate instruction set) does not define a
"tailcall
instruction", so Clang also ICEs there. Just mentioning it for
completeness.
Also aarch64-linux if I remember correctly.
One could use a trampoline to deal with the loading of additional state,
but I do
not want to go down that route for coroutines, if possible - since we
already have
a state frame, it seems better to me to extend the ABI for that to include
space
for target-specific data at a known offset from the frame pointer.
Iain
What about tailcalls between DSOs?
What issues are there around DSOs? Clang/LLVM don't treat these
specially AFAIK, and it seems that tail calls through a PLT should
work okay?
No, some targets have additional requirements for calls that potentially
go via
a (PIC) PLT. The most well-known example is probably 32-bit x86, which
requries the %ebx register to hold the address of GOT when entering a PLT
trampoline. Since %ebx is callee-saved, this makes tailcalling impossible.
LLVM solves this by transforming such calls to "no-plt" GOT-indirect
calls under
'musttail', so evidently it does treat them specially.
Another example is mips64, where even non-PIC PLT is special (but looks
like
LLVM does not do any tailcalls on mips64 at all).
Alexander
