On Thu, Dec 09, 2021 at 11:57:19AM +0100, Florian Weimer wrote: > * Segher Boessenkool: > > > On Wed, Dec 08, 2021 at 04:17:33PM -0700, Jeff Law via Gcc-help wrote: > >> On 12/7/2021 3:38 PM, Bradley Lucier via Gcc-help wrote: > >> >So I've been investigating whether gcc's -foptimize-sibling-calls > >> >option (for which I've found very little documentation) might produce > >> >similar results. > >> The option has been around for probably 20+ years at this point, you > >> just might not have been aware of it. They try, but do not guarantee > >> tail call optimization. They have all kinds of checks that might cause > >> any particular call site to be rejected for tail call elimination. It's > >> enabled by default at O2 or higher. > > > > (Including -Os.) > > > > GCC will never not do a tail call if it knows any way to do it. > > GCC will never do a tail call if the target function is known not to > return normally, to preserve the stack backtrace. Yes, and that is arguably a bug. We usually can generate better code without this artificial limitation, and there are many other cases where we do similar optimisations that make non-DWARF backtraces harder. Such backtraces are of questionable value these days since we have inlining as well as outlining (or partial inlining at least). I think we have a PR open for this already? This usually does not matter much at all, since such paths are called at most once per program run. Some targets will never tail call, and some have further limitations, but on most targets (more mainstream targets anyway) you get tail calls wherever you could. Segher
