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

[Dan Gohman]

On Tue, Jun 25, 2013 at 9:09 AM, Stephen Lin <swlin at post.harvard.edu> wrote:

>
> On Tuesday, June 25, 2013, Dan Gohman wrote:
>
>> Even with smarter heuristics, you're still breaking mid-level
>> optimizations in some cases. I think the fact that you're trying to
>> represent the return value at the IR at all is awkward.
>>
>
> I'm not sure what those cases are. The 'returned' attribute will not keep
> a return value alive if the argument would be dead otherwise, so it's not
> preventing further dead arg elimination (the argument marked with
> 'returned' would not be eliminated even if the return value were to be
> because its being used for something else.)
>
> The only possible benefit I could think of is if the argument were only
> live in the very beginning of the function and dead for the rest of it
> other than being used for the return value. At that case it's costing a
> single spill in the very worst case, as far as I can tell. I can't think of
> a mid-level optimization that would be affected.
>

Here's an attempt at an example to make this more concrete, though I'm not
completely sure we're talking about the same case:

define i8* @foo(i8* returned %a) {
  call void @do_stuff_that_does_not_use_a();
  ret i8* %a
}

...
%x = expensive_thing
%t = call i8* @foo(i8* %x)
... (further uses of %x that may eventually be discovered to be dead)

If %x is ultimately dead, how do we get to the point of removing it? It's
not trivially dead because it has a use. If you teach dead-arg elimination
to keep it live, then it won't die even if its other uses are ultimately
removed.

It'd be more natural to have the function return void, and treat it
>> specially in codegen. I propose the following alternative.
>>
>> Keep the 'returned' argument attribute, and add a 'returnsarg' function
>> attribute. Then, the semantics of 'returned' are that it is ignored unless
>> it is the first 'returned' argument in a function that is marked
>> 'returnsarg' and has a void return type. Then at the codegen level, the
>> function is translated as if it had the return type of its first 'returned'
>> argument. As an optimization, codegen can rewrite uses after the call to
>> use the return value.
>>
>> That way, DeadArgElimination and all the other mid-level optimizations
>> can run at full strength, and you can still get your optimization. What do
>> you think?
>>
>> Dan
>>
>>
>
> But the callee actually has to return that argument somehow for the
> attribute to be valid. Are you proposing that the functions marked with
> 'returnsarg' silently save an argument and return it in codegen without
> actually representing that return in IR? If so, there's no benefit to
> taking away the return value because code gen is going to have to keep
> track of it somehow anyway to return it, and it will have to have special
> machinery to do so in a way that doesn't waste an extra register
> unnecessarily (it's not like a normal callee saved register because the
> value is also going to be used in the body of the function)
>

Yes. I'm suggesting this because the optimization you're proposing really
is a low-level calling convention optimization that doesn't conceptually
belong in the mid-level optimizer as more than attributes.


>
> Also, just because the return value is unused at the IR level in this case
> doesn't meant it won't ever be used. You could canonicalize the IR
> to remove uses of the return value if you wanted to, but how does a front
> end express code before it is canonicalized?
>

The front-end would just emit uses of the outgoing argument from the
caller. WRT memcpy, LLVM's memcpy intrinsic has a void return type already,
for example, so this is something you'd want to figure out anyway.

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130625/6cb131ff/attachment.html>