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

Evan Cheng evan.cheng at apple.com
Thu Apr 18 22:58:02 PDT 2013



Sent from my iPad

On Apr 18, 2013, at 9:59 PM, Stephen Lin <swlin at post.harvard.edu> wrote:

> 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.

Yes, I understand this code was already using recursion. But if you can get rid of recursion at the same time, that's doubly good. :)

I want to be clear it's not a requirement for this patch's acceptance. It seems reasonable. I want to be extra carefully though. Tail code bugs are notoriously subtle. How are you testing this patch? Are you able to run the entire test suite? Which targets?

Evan

> 
> -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



More information about the llvm-commits mailing list