It’s Not Always iCache

Re:It’s Not Always iCache by steerablesafe on Monday July 12, 2021 @01:50PM (#27813040)

One optimization I never saw is to adjust the stack within the function, other than the beginning and end. Because of this inlining can significantly blow up stack space.

https://godbolt.org/z/Gaa4MEMnK

[ Parent | on HN ]

Re:It’s Not Always iCache by neerajsi on Monday July 12, 2021 @02:47PM (#27813611)

The optimization exists in MSVC, LLVM, and GCC. It's called "shrink wrapping". MSVC may do it more aggressively when profile information is available.

See https://github.com/gcc-mirror/gcc/blob/master/gcc/shrink-wra... or https://llvm.org/doxygen/ShrinkWrap_8cpp_source.html.

[ Parent | on HN ]

Re:It’s Not Always iCache by leni536 on Monday July 12, 2021 @03:32PM (#27814057)

None of gcc, clang or msvc deallocate the frame or part of the frame in `baz2` before calling `bar` the first time here:

https://godbolt.org/z/rvx36sM74

What I would like to like is something like the generated call of `call_foo1` substituted verbatim into the generated code of `baz1` in the place of the function call. That way at the point of calling `bar` there is much less stack space allocated, minimizing stack usage.

But maybe this would pessimize other things, or for some weird reason is actually incorrect.

gcc at least deallocates the stack before tail-calling `baz`, I don't know if that is "shrink wrapping" or just plain TCO.

[ Parent | on HN ]

Re:It’s Not Always iCache by ndesaulniers on Monday July 12, 2021 @03:36PM (#27814103)

You can get into weird cases with DWARF based unwinders when two paths through a function with different stack depths makes it impossible to reliably unwind.

LLVM has bugs in this regard with calls to variadic calls, since after a certain number of arguments have been passed in registers, you start pushing parameters on the stack (ABI dependant).

[ Parent | on HN ]