Apologies, I misspoke slightly...the attribute itself does not affect code generation of the callee, only the caller. <span></span>But the return value being present can affect whether a tail call is formed, etc.<br><br>On Friday, June 21, 2013, Stephen Lin  wrote:<br>
<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>
<br>
That said, if you think there's a better approach to this that's more<br>
robust and retains the optimization benefits for the ARM C++ ABI,<br>
please let me know!<br>
<br>
Stephen<br>
<br>
On Fri, Jun 21, 2013 at 2:17 AM, Nick Lewycky <<a href="javascript:;" onclick="_e(event, 'cvml', 'nicholas@mxc.ca')">nicholas@mxc.ca</a>> wrote:<br>
> I'm sorry, I seem to have missed the discussion that led up to the<br>
> 'returned' attribute being added to llvm ir. Could you please point me to<br>
> that?<br>
><br>
> I've read the comment in the patch and I'm not sure I'm convinced. Offhand,<br>
> it seems that the correct thing to do is to remove the 'returned' attribute<br>
> if we change the return type of the function to void. The fact we can change<br>
> the function that way is implies that the ABI arguments are moot since we<br>
> have control over the function's calling convention, since we control the<br>
> function and all its callsites.<br>
><br>
> Nick<br>
><br>
> Stephen Lin wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> This patch makes the DeadArgElimination IPO pass treat any return<br>
>> value of any function with a 'returned' argument as live even if there<br>
>> are no uses. This is meant to allow the clang patch committed as<br>
>> revision r184205 (and subsequent minor fixes) to be recommitted after<br>
>> being reverted in revision r184205 due to broken builds on ARM when<br>
>> compiling with LTO.<br>
>><br>
>> The 'returned' attribute is relatively new and indicates, as an<br>
>> optimization hint to the caller, that a function always returns the<br>
>> value of an argument as its return value. In the intended use cases,<br>
>> it is almost always better to leave the return value on the function<br>
>> than to take it off, because it's essentially free. (Specifically, for<br>
>> a 'this'-returning constructor/destructor in the ARM C++ ABI using the<br>
>> ARM calling convention, the 'this'-argument and the return value as in<br>
>> the same register so the caller and callee basically can both leave it<br>
>> untouched unless there is significant register pressure.)<br>
>><br>
>> The patch includes comments describing the rationale for retaining the<br>
>> return value in these cases and also includes a note that this should<br>
>> be reinvestigated if 'returned' is applied more liberally in the<br>
>> future.<br>
>><br>
>> Any and all feedback is highly appreciated.<br>
>><br>
>> Stephen<br>
>><br>
>> <rdar://problem/14209661><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> llvm-commits mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'llvm-commits@cs.uiuc.edu')">llvm-commits@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
><br>
</blockquote>