<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 16, 2014 at 1:29 AM, Arnaud A. de Grandmaison <span dir="ltr"><<a href="mailto:arnaud.degrandmaison@arm.com" target="_blank">arnaud.degrandmaison@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">Hi David,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">In principal, giving more lifetime info can only improve stack slot sharing and reduce runtime stack usage, which is critical for us in the embedded world.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">I did not test that on a wide code base yet, but we had a customer reporting an issue where llvm/clang was producing code with a stack usage significantly worse than gcc. To make things worse, in their case their code was heavily recursive, to the point where using clang was simply not an option: they are forced to use gcc </span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">L</span><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">This patch only adds lifetime markers to big enough (>32 bytes) objects, consistent with what is done for named temporaries. I do not know how this 32 bytes threshold has been choosen, but there is for sure a compile time / stack size gain trade-off to be made. My experiments have shown that for our customer case, the threshold should be lower: 16-bytes. But changing this threshold would require a separate thread on this list, as well as much more measurements.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">The improvements I have been able to get, by visual inspection of the generated assembly code, for a single call of the hot functions were:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">   | GCC | Clang | LT-32 | LT-16 |<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">===+=====+=======+=======+=======+<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">F1 | 432 |   608 |   608 |   400 |<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">F2 | 432 |   640 |   640 |   432 |<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">F3 | 384 |   368 |   368 |   192 |<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">F4 | 320 |   400 |   400 |   224 |<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">Stack size is expressed in bytes.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">GCC version 4.8<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">LT-32 is clang with this patch (default 32 bytes threshold for all temporaries).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">LT-16 is clang with this patch and a 16 bytes threshold for all temporaries.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">I believe bootstrapping clang could be a good testcase and will be needed when we will address the real problem in a separate discussion: what threshold should we use ?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">Very strangely to me coming from the embedded world, I have not found how to measure a program stack usage on linux, so if you have any idea, I am glad to hear about it.</span></p></div></div></blockquote><div><br></div><div>I'm not sure what the nicest way to do it for the running program or examining a binary, but I would /imagine/ that LLVM might have a counter/statistic for stack usage. I believe LLVM has some way to record statistics about optimizations, etc, for debugging the compiler. So if it doesn't have a "stack size" stat counter, it could hopefully be added.<br><br>But you're right, for now - adding more should be generally better. I'm not sure if there's a concern that adding too many (given that there's a threshold, I assume someone tried it without a threshold and found that it created too much metadata) intrinsics like this - so there might be some need to show cost/benefit... (maybe looking at the commit archive to find the original commits, those that added the threshold, etc)<br><br>(this is way out of my depth/area of interest - but just replying with suggestions/ideas to both make the conversation more visible, give you some ideas that might pre-empt ideas from other more knowledgeable reviewers, etc)<br><br>- David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">Cheers,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d">Arnaud<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal" style="margin-left:36.0pt"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>] <br><b>Sent:</b> 16 September 2014 01:25<br><b>To:</b> Arnaud De Grandmaison<br><b>Cc:</b> llvm cfe<br><b>Subject:</b> Re: [PATCH] Emit lifetime start/end for unnamed objects --- take 3<u></u><u></u></span></p><div><div class="h5"><p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-left:36.0pt">I'm hardly an expert on this stuff - but just curious: what sort of testing did you put this through? Bootstrap Clang? Were you able to gather any stats on reduced stack usage with this improvement to lifetime markers?<u></u><u></u></p></div><div><p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-left:36.0pt">On Mon, Sep 15, 2014 at 4:05 PM, Arnaud A. de Grandmaison <<a href="mailto:arnaud.degrandmaison@arm.com" target="_blank">arnaud.degrandmaison@arm.com</a>> wrote:<u></u><u></u></p><div><div><p class="MsoNormal" style="margin-left:36.0pt">Hi All,<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt"> <u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">Please find attached a patch which teaches clang to emit lifetime.start / lifetime.end markers for unnamed temporary objects.<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt"> <u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">This patch can greatly reduce the stack usage of some C++ code, where it is so easy to have short lived unnamed temporaries.<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt"> <u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">As noted in the subject, this is my third attempt: my previous attempts failed to handle correctly the lifetime extended temporaries, and I have had a hard time to understand the CleanupScope. It all boiled down to the fact that the body of a function is not considered a full CleanupScope (for debug information reasons), so in the case of lifetime extended objects at the top level of the function body, with a trivial destructor  + lifetime.end marker, the lifetime markers were simply not considered, firing an assert in ~CodeGenFunction. All cases are now covered by testcases.<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt"> <u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">I would appreciate if someone knowledgeable with the lifetime extended temporaries & cleanup scopes could give a look to this patch.<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt"> <u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">Cheers,<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">--<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt">Arnaud A. de Grandmaison<u></u><u></u></p><p class="MsoNormal" style="margin-left:36.0pt"> <u></u><u></u></p></div></div><p class="MsoNormal" style="margin-right:0cm;margin-bottom:12.0pt;margin-left:36.0pt"><br>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><u></u><u></u></p></div><p class="MsoNormal" style="margin-left:36.0pt"><u></u> <u></u></p></div></div></div></div></div></blockquote></div><br></div></div>