llvm dev - Jan 2020 - Stack Usage is more in the libunwind library .

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200127/2548841a/attachment.html>

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>

Thank you David ,

unfortunately, the wrapper doesn't work for us :( .
>> then you'd need to consider deeper changes to populate (aka:
parseFDEInstructions)
That , something we need to do so and another way we are thinking to
refactor with having the lock or atomic access for this global .

Thank you again
~Umesh


On Mon, Jan 27, 2020 at 10:21 PM David Blaikie <dblaikie at gmail.com>
wrote:
> 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/20200128/fc09eba0/attachment.html>