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

[Stephen Lin]

On Fri, Jun 21, 2013 at 10:21 AM, Stephen Lin <swlin at post.harvard.edu> wrote:
>>> IMO, the presence of the returned attribute just doesn't seem like a very
>>> good heuristic for predicting whether the returned attribute should be used.
>>> I mean, sure, an IR optimizer can't predict what CodeGen will do with
>>> complete accuracy, but it shouldn't be hard to make a decent guess that's
>>> better than what the frontend is doing, given that the frontend has no idea
>>> what the callers or the callee actually look like.
>>>
>>> -Eli
>>
>> Well, it's a pretty good heuristic now, given the very limited usage
>> of this attribute, but yes, I agree, it might not be in the future.
>>
>> I would definitely be happy proactively putting in a better heuristic
>> now but I am not really sure how to do so. At the very minimum it
>> seems like it would require a lot of dataflow analysis that is not
>> currently done in DeadArgumentElimination.
>
> I meant to add that suggestions are definitely welcome... :)
>
>>
>> Stephen

OK, I tweaked it to keep alive the return value only if there's
something other than the 'return' keeping the 'returned' argument
alive. Also, call sites with 'returned' attached to a parameter won't
keep a return value alive on their own; the attribute will be dropped
instead if the return value is changed.

Please let me know what you think.

Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: returned-lto-fix.patch
Type: application/octet-stream
Size: 5756 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130621/2880eb69/attachment.obj>