[PATCH] D147714: [Attr] Introduce [[clang::nonportable_musttail]] as less strict version of [[clang::musttail]]

Josh Haberman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 24 13:46:01 PDT 2023

haberman added a comment.

> Such a definition doesn't make much sense because for some targets tail call optimization isn't available at all.
> Eg. Wasm w/o tail call proposal, xtensa windowed abi.

That is true. But what is the correct behavior if you try to use `[[clang::musttail]]` on such a target? In my case, I want to get a compiler error, because if a tail call cannot be performed, the algorithm is incorrect (it will cause stack overflow at runtime).

There are three possible semantics that I can see:

1. Perform a tail call if possible.
2. Perform a tail call, fail to compile if this is not possible (`[[clang::nonportable_musttail]]`)
3. Perform a tail call, fail to compile if this is not possible //or// if the function signatures between caller and callee differ in ways that make tail calls difficult on some platforms (`[[clang::musttail]]`)

Both (2) and (3) would fail to compile on Wasm without tail calls. If all you want is (1), that doesn't require any attribute (the optimizer will do it automatically).



More information about the llvm-commits mailing list