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

[Stephen Lin]

> It means "put this value in that register!" to the callee and "assume this
> value comes back in that register!" to the caller. The only thing stopping
> it from being an IPA-RA solution is the fact that it only applies to one
> register/argument. Remove that check in the verifier and give the backend a
> list of returning registers and -- blammo! -- you've got support for full
> blown interprocedural register allocation, just plug in your heuristics. In
> my mind, the fact that it only applies to one register does not save it from
> this criticism.

But it's not really that because the attribute can just as easily
apply when the argument is smaller than a single register, spans
multiple registers, is passed on the stack, or that the target backend
is one in which the concept of registers and stacks doesn't apply at
all. It's really a semantic attribute that just happens to have an
easy interpretation in terms of registers in a specific case for a
specific backend, so that's where the attribute is taken advantage of
most initially, but other IR passes could easily be taught to take
advantage of the attribute in other ways (doing dataflow analysis
across calls, for example.)

Note that it would not, at this time, be wise to simply do a RAUW on
the return value with the 'returned' argument, since this is likely to
cause codegen to generate worse code (basically, while using the
'returned' argument is probably better for IR analysis, using the
return value is usually, but not always, better for codegen...there's
no hard and fast rule to use at the IR level which won't cause
regressions in some cases until the register allocator natively
understands how to intelligently choose between two virtual registers
that hold the same value.) This is purely a limitation of our current
CodeGen infrastructure and not a fundamental limitation on the
usefulness of the attribute at the IR level.

-Stephen