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

[Stephen Lin]

> No, I don't have any alternatives, other than interprocedural coordination
> of code generation. Do you have any alternatives?

The only thing I can think of is a few more heuristics to avoid
keeping the return value in cases where it is "obviously" not useful
to the caller.

>
>>
>> Also, in theory, some mid level optimization could be done, even if it
>> is not done now. A 'returned' argument implies the argument and return
>> value are aliases of each other in all code dominated by the function
>> call, so IR optimizers would be free to replace one with the other. As
>> mentioned in other e-mails, it is, the problem is that, in the general
>> case, it is difficult to know which alternative to pick; however, an
>> IR pass could, at a minimum, canonicalize this:
>>
>>   %struct.A = type { i32 }
>>
>>   declare %struct.A* @a_ctor(%struct.A* returned)
>>   declare void @bar(%struct.A*)
>>
>>   define %struct.A* @foo() {
>>   entry:
>>     %a = alloca %struct.A, align 4
>>     %b = call %struct.A* @a_ctor(%struct.A* %a)
>>     call void @bar(%struct.A* %a)
>>     ret %struct.A* %b
>>   }
>
>
> The canonical form would be:
>
> %struct.A = type { i32 }
>
>   declare %struct.A* @a_ctor(%struct.A* returned)
>   declare void @bar(%struct.A*)
>
>   define %struct.A* @foo() {
>   entry:
>     %a = alloca %struct.A, align 4
>     %b = call %struct.A* @a_ctor(%struct.A* %a)
>     call void @bar(%struct.A* %a)
>     ret %struct.A* %a
>   }
>
> In other words, it's advantageous to see the actual value, and there's no
> mid-level optimizer benefit to seeing the return value.

I understand your point; I think canonicalization was not quite what I
meant. It understand that it would be useful, from a mid-level
optimizer perspective, to canonicalize usage to the argument rather
than the return value, since the aliasing information would be just
noise for an SSA representation with infinite virtual registers.

But definitely, the information that the physical register containing
the return value and argument are aliases of each other should not be
lost, and code generation should not be forced to choose one or the
other before register allocation. So even if there is a
canonicalization to use the argument for the mid-level optimizers,
there needs to be some way to recover the semantics of ""select i1
undef, %struct.A* %argument, %struct.A* %return_value"" somewhere and
to use it to optimizer register allocation, either as a late IR pass
or during SelectionDAG lowering.

Stephen