[PATCH] Teach DeadArgElimination not to eliminate return values of functions with 'returned' arguments

Nick Lewycky nicholas at mxc.ca
Fri Jun 21 02:17:29 PDT 2013


I'm sorry, I seem to have missed the discussion that led up to the 
'returned' attribute being added to llvm ir. Could you please point me 
to that?

I've read the comment in the patch and I'm not sure I'm convinced. 
Offhand, it seems that the correct thing to do is to remove the 
'returned' attribute if we change the return type of the function to 
void. The fact we can change the function that way is implies that the 
ABI arguments are moot since we have control over the function's calling 
convention, since we control the function and all its callsites.

Nick

Stephen Lin wrote:
> Hi,
>
> This patch makes the DeadArgElimination IPO pass treat any return
> value of any function with a 'returned' argument as live even if there
> are no uses. This is meant to allow the clang patch committed as
> revision r184205 (and subsequent minor fixes) to be recommitted after
> being reverted in revision r184205 due to broken builds on ARM when
> compiling with LTO.
>
> The 'returned' attribute is relatively new and indicates, as an
> optimization hint to the caller, that a function always returns the
> value of an argument as its return value. In the intended use cases,
> it is almost always better to leave the return value on the function
> than to take it off, because it's essentially free. (Specifically, for
> a 'this'-returning constructor/destructor in the ARM C++ ABI using the
> ARM calling convention, the 'this'-argument and the return value as in
> the same register so the caller and callee basically can both leave it
> untouched unless there is significant register pressure.)
>
> The patch includes comments describing the rationale for retaining the
> return value in these cases and also includes a note that this should
> be reinvestigated if 'returned' is applied more liberally in the
> future.
>
> Any and all feedback is highly appreciated.
>
> Stephen
>
> <rdar://problem/14209661>
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list