[llvm-dev] Stack Usage is more in the libunwind library .
Umesh Kalappa via llvm-dev
llvm-dev at lists.llvm.org
Tue Jan 28 00:16:31 PST 2020
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>
More information about the llvm-dev
mailing list