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

[Stephen Lin]

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.

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)

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?

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130625/79a330fb/attachment.html>