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

[Chris Lattner]

On Jun 27, 2013, at 4:28 PM, Nick Lewycky <nlewycky at google.com> wrote:
> 
> Okay. The questions that remain in my mind are: should we have a step in FunctionAttrs to deduce 'returned'? Are there any other IR-level optimizations we can apply when we see a returned attribute? If somebody asks for a code review of a patch which adds a pass that turns internal-linkage void returning functions into argument returning, just for the benefit of adding the 'returned' attribute, what's the answer?

My take is that it makes sense to infer the returned attribute when a function body is already returning one of its arguments.  This *just* gives more information to codegen on the caller side, and should allow reducing register pressure in some cases with no cost in the other cases.

OTOH, I *don't* think we should have a mid-level optimization that starts returning an argument in a function just to mark it returned... at least without a really good cost model that knows about ABIs and register pressure in the callee.

-Chris