3 ms·

(for context: -fomit-frame-pointer causes the FP to not be saved on the stack, stack unwinding then relies on DWARF or compiler-internal information to unwind t

(for context: -fomit-frame-pointer causes the FP to not be saved on the stack, stack unwinding then relies on DWARF or compiler-internal information to unwind the stack.) I don't see how that would have an effect on TCO, as the storing or not of the FP (beyond in a register) is not part of the calling convention AFAIK. - Only externally linked functions have to conform, so I can understand if TCO does not apply to mutually recursive external functions. Perhaps with LTO it can? - Even an external function that calls itself in tail-position should be TCO-able under -fno-omit-frame-pointer. The compiler reuses the same frame and generates a jump instead of a full function call.

moonchild 6y ago
> I don't see how that would have an effect on TCO, as the storing or not of the FP (beyond in a register) is not part of the calling convention AFAIK Sysv abi[1], section 3.2.2: > In addition to registers, each function has a frame on the run-time stack So it is part of the calling convention. But again, this is IMO pedantry that doesn't really matter. > Even an external function that calls itself in tail-position should be TCO-able under -fno-omit-frame-pointer. The compiler reuses the same frame and generates a jump instead of a full function call Yes, I agree. Just interpreting what I think he meant. 1. https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x...