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

With our analysis and found that “typename CFI_Parser::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

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))

Thank you David ,

unfortunately, the wrapper doesn’t work for us :frowning: .

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