<div dir="ltr">Thank you David ,<div><br></div><div>unfortunately, the wrapper doesn't work for us :( .</div><div><br></div><div>>> then you'd need to consider deeper changes to populate (aka: parseFDEInstructions)</div><div>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 .</div><div><br></div><div>Thank you again</div><div>~Umesh </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 10:21 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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).<br><br>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.<br><br>One simple thing to do would be to write a wrapper around parseFDEInstructions that only retrieves that field. Something like this:<br><br>  struct BigStruct { /* lots of fields */ int TheOneFieldYouNeed; };<br>  void populate(BigStruct*);<br>  void getOnlyTheFieldYouNeed(int *) {<br>    BigStruct B;<br>    populate(&B);<br>    return B.TheOneFieldYouNeed;<br>  }<br><br>& 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))</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 2:49 AM Umesh Kalappa via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi All,<br><br></div><div>We recently migrated to llvm 9 from gcc -7 and found that the stack usage is more  like 5K in the below function  <br><br></div><div>getInfoFromDwarfSection() @<a href="https://github.com/llvm-mirror/libunwind/blob/master/src/UnwindCursor.hpp#L1484" target="_blank"> line : 1484 </a> <br><br>With our analysis and found that  "typename CFI_Parser<A>::PrologInfo prolog" local data is taking up almost 4K space.<br>So we thinking to refactor the code by pushing the "prolog" to a global scope.<br>Any comments on our approach will be appreciated<br><br></div><div>Thank you </div><div>~Umesh <span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre-wrap;background-color:rgb(255,251,221)"><br></span></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>