<div dir="ltr">On Fri, Jun 21, 2013 at 8:04 AM, Stephen Lin <span dir="ltr"><<a href="mailto:swlin@post.harvard.edu" target="_blank">swlin@post.harvard.edu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<br>
<br>
Here is the patch that added the attribute:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171972.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130415/171972.html</a><br>
.<br>
<br>
In the cases where 'returned' will be generated by the front-end<br>
immediately, which is ARM C++ 'this'-returning constructors and<br>
destructors, 'returned' generally allows both the caller and callee to<br>
generate better code, because the the first parameter (for passing<br>
'this') and the return value are both in same register. So to return<br>
'this', the constructor or destructor doesn't have to do anything<br>
extra to return 'this': it just has to not touch with register. On the<br>
other hand, the caller can use the information of the 'this' return to<br>
elide save/restoring the 'this' pointer across the call, reducing a<br>
few instructions. 'this'-returning constructors and destructors were<br>
explicitly added to the ABI for this optimization purpose.<br>
<br>
Admittedly, there are situations where it would be better to drop the<br>
return value. For example, if the argument and return value are both<br>
superfluous (i.e. the constructor/destructor doesn't do anything with<br>
the 'this' pointer but pass it straight through) and the caller isn't<br>
going to have the 'this' pointer of the callee handy in a register<br>
anyway, then it would be better to get rid of both; however, it is<br>
rare for a constructor or destructor to never use 'this'. Furthermore,<br>
if there's significant register pressure in either the caller or the<br>
callee, then maybe 'this' is going to have to be save/restored on both<br>
sides anyway, and dropping the return value will keep it from having<br>
to be restored on the callee side before being returned, etc.<br>
<br>
Unfortunately, as far as I can tell, there's not really any way for an<br>
IR-level pass to detect these kinds of situations without lots of<br>
target and backend-implementation specific details, and, since for<br>
now, the attribute is only being used in a very specific situation<br>
where (I believe) it's usually more profitable to allow code<br>
generation to take advantage of the extra information provided by<br>
'returned', I decided to go with the default of leaving it in always.<br></blockquote><div><br></div><div>Note that your argument could be reinterpreted as a proposal for an IR optimizer to add the "returned" attribute to constructors/destructors on x86.<br>
<br>IMO, the presence of the returned attribute just doesn't seem like a very good heuristic for predicting whether the returned attribute should be used.  I mean, sure, an IR optimizer can't predict what CodeGen will do with complete accuracy, but it shouldn't be hard to make a decent guess that's better than what the frontend is doing, given that the frontend has no idea what the callers or the callee actually look like.<br>
<br></div></div><div class="gmail_quote">-Eli<br></div></div></div>