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

[Stephen Lin]

> 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?
>
>
> I don't see that transformation being profitable but I can be proven wrong.
>
> Evan

Well, I'm not advocating doing this, but theoretically if we improved
CodeGen to generate optimally efficient code around calls to functions
with 'returned' in all cases (i.e. not just the ARM case where the
argument and return value are in the same register, and not only in
the case that the argument fits exactly in one GPR), then I could see
the possibility of a decent target-independent heuristic for this:
basically, you would do this if it could consistently reduce the live
range of a IR value in most/all callers (i.e. the variable would be
consumed by the function call as its last use, and the return value
would be used thereafter), so the value does not have to be live
across the call.

It wouldn't be guaranteed to work for all targets, though, and it
would actually impede rather than promote other mid-level optimization
opportunities usually, so it probably would have to be done in some
kind of final CodeGenPrepare step with some target-specific knowledge.
(I'll ignore the issue of whether or not CodeGenPrepare-type passes
are a good idea.)

Stephen