[PATCH] Allow tail call optimization through multiple/nested struct extractions/insertions

[Stephen Lin]

Hmm, that's an interesting question. For the trivial single-operand
no-ops, it should be pretty easy. The extractvalue/insertvalue cases
are the tricky ones, as would be callinsts and invokeinsts with
multiple 'returned' (but I suppose that should just be disallowed...it
doesn't seem like it would ever be useful.)

I'm under the impression that this solution doesn't recurse more than
the original one did, for the cases that the original one supported,
but since this supports more cases (especially with the addition of
'returned') the recursion could be an issue. Let me think it through
and get back to you.

-Stephen

On Thu, Apr 18, 2013 at 11:27 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> Hi Stephen,
>
> Is it possible to rewrite sameNoopInput without recursion?
>
> Thanks,
>
> Evan
>
> Sent from my iPad
>
> On Apr 18, 2013, at 6:13 AM, Stephen Lin <swlin at post.harvard.edu> wrote:
>
>> Hi,
>>
>> This patch generalizes target-independent tail call opportunity
>> detection to handle cases where a struct is decomposed and recomposed
>> multiple times, is nested within another struct, or any combination of
>> both along with any combination of other intermediate no-ops. It also
>> allows tail calls when structs are partially undefined, as long as all
>> defined values have the appropriate origins.
>>
>> Finally, it adds an explicit check for the all-zero getelementptr
>> case; it seems like the case already works most of the time due to
>> other reductions, but I'm adding an explicit check to minimize phase
>> ordering issues and because an in-development patch depends on it.
>>
>> Please kindly review.
>> Stephen
>> <tail-call-nested-struct.patch>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits