This is an archive of the discontinued LLVM Phabricator instance.

[libunwind] Improve unwinder stack usage - II
ClosedPublic

Authored by rmaprath on May 17 2016, 4:03 AM.

Details

Summary

This is a follow-up to D20119 (although not dependent on it).

unwind_phase1 and unwind_phase2 allocate their own copies of unw_cursor_t buffers on the stack. This can blow-up stack usage of the unwinder depending on how these two functions get inlined into _Unwind_RaiseException. Clang seems to inline unwind_phase1 into _Unwind_RaiseException but not unwind_phase2, thus creating two unw_cursor_t buffers on the stack.

One way to work-around this problem is to mark both unwind_phase1 and unwind_phase2 as noinline. I chose to take the less macro-dependent approach and explicitly allocate a unw_cursor_t buffer and pass that into unwind_phase1 and unwind_phase2 functions.

This shaves off about ~1000 bytes of stack usage on ARM targets.

The current patch together with D20119, shaves off about roughly 2KB of stack usage.

Diff Detail

Event Timeline

rmaprath updated this revision to Diff 57452.May 17 2016, 4:03 AM
rmaprath retitled this revision from to [libunwind] Improve unwinder stack usage - II.
rmaprath updated this object.
rmaprath added reviewers: jroelofs, bcraig.
rmaprath added a subscriber: cfe-commits.
rmaprath updated this object.May 17 2016, 4:04 AM
bcraig edited edge metadata.May 25 2016, 9:31 AM

LGTM. You probably need to get an approval from someone else though, as I haven't really established myself in the libunwind code base.

As a side note... one of these days clang / llvm stack compaction may actually work reasonably well, and tricks like this won't be necessary. I look forward to that day.

LGTM. You probably need to get an approval from someone else though, as I haven't really established myself in the libunwind code base.

As a side note... one of these days clang / llvm stack compaction may actually work reasonably well, and tricks like this won't be necessary. I look forward to that day.

Thanks.

Do you know if there are clang / llvm passes that attempts to achieve some sort of stack compaction? I couldn't find much.

@jroelofs: Gentle ping.

/ Asiri

jroelofs accepted this revision.May 27 2016, 8:15 AM
jroelofs edited edge metadata.

Probably worth doing the same thing for the non-EHABI non-SJLJ implementation, too (that can of course go in a separate commit).

LGTM

This revision is now accepted and ready to land.May 27 2016, 8:15 AM
This revision was automatically updated to reflect the committed changes.

Do you know if there are clang / llvm passes that attempts to achieve some sort of stack compaction? I couldn't find much.

I'm not sure if it belongs to its own pass, or if it is part of another pass, but the algorithm and discussion revolve around the term "stack coloring". The code lives in llvm lib/CodeGen/StackColoring. Here's a recent review that messed with it: http://reviews.llvm.org/D18827