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

[Stephen Lin]

> We shouldn't require knowledge of the target and the calling conventions to perform optimization at the IR level. I believe the important thing here is for DAE to be consistent. It should either keep the argument and the "returned" attribute or remove the argument as well as the attribute.

And to be clear, this is what is happening in my latest patch. The
return value is only preserved in the case that the argument would
have been preserved by DAE no matter what already; basically, either
they both go or neither do.

>
>>
>> Anyhow, as I said I'm not going to block this patch because I don't have ideas on what would be a better way to do it, but please get an OK from Dan first.
>
> This is a long thread so I didn't read all of it. If I understand correctly, Dan's proposal is to change the function prototype to return void and recognize the optimization opportunity at codegen. At the codegen level, the handling of function arguments and return values are scattered all over the place. It's going to add more complexity and I really do not see how it would make the optimization more powerful.

I also think it should be noted that there's nothing preventing this
optimization strategy from being adopted in the future, if we ever
implement smart and fully general interprocedural register allocation
for internalized functions. However, it would be simple to change DAE
to do this, if and when that ever happens. Furthermore, that would not
eliminate the need for the 'returned' attribute to handle the single
return value, non-internalized, cross-TU case.

Stephen