[llvm-dev] Stack Usage is more in the libunwind library .

[David Blaikie via llvm-dev]

Moving things from local to global, and thus making functions non-reentrant
isn't usually an awesome idea (though if folks more familiar with libunwind
reckon it's fine for the usage there, that's cool).

It looks like the use of PrologInfo in getInfoFromDwarfSection is only to
find the spExtraArgSize? So perhaps the APIs there could be refactored to
not be so expensive when only that field is required - rather than
requiring a large allocation.

One simple thing to do would be to write a wrapper around
parseFDEInstructions that only retrieves that field. Something like this:

  struct BigStruct { /* lots of fields */ int TheOneFieldYouNeed; };
  void populate(BigStruct*);
  void getOnlyTheFieldYouNeed(int *) {
    BigStruct B;
    populate(&B);
    return B.TheOneFieldYouNeed;
  }

& then just use that - assuming that function doesn't get inlined, it
should keep the stack usage of other parts of that function down (unless
it's stack usage during the evaluation of populate specifically that's the
problem - then you'd need to consider deeper changes to populate (aka:
parseFDEInstructions))

On Mon, Jan 27, 2020 at 2:49 AM Umesh Kalappa via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi All,
>
> We recently migrated to llvm 9 from gcc -7 and found that the stack
> usage is more  like 5K in the below function
>
> getInfoFromDwarfSection() @ line : 1484
> <https://github.com/llvm-mirror/libunwind/blob/master/src/UnwindCursor.hpp#L1484>
>
>
> With our analysis and found that  "typename CFI_Parser<A>::PrologInfo
> prolog" local data is taking up almost 4K space.
> So we thinking to refactor the code by pushing the "prolog" to a global
> scope.
> Any comments on our approach will be appreciated
>
> Thank you
> ~Umesh
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200127/0e1c8471/attachment.html>