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

[Stephen Lin]

No problem, I managed to get rid of most of the recursion, actually
(see updated patch); it was an interesting exercise. The only
recursion left is to handle extractions and insertions...I could
probably do something with that too but it requires a lot more book
keeping. Do you think it's worth it?

I've added tests to CodeGen/X86/tailcall-64.ll to test for the new
positive cases. I thought of adding cases to verify that there aren't
any false positives because I had a hard time thinking of meaningful
false positive cases, but I can try harder to think of some. I also
didn't add tests for other targets since this is all
target-independent, but I don't mind doing that if you think it's
worthwhile.

The entire LNT nightly test suite passes, except for an execution time
limit on one test, which was already failing for me before this. Is
there anything else I should test?

Stephen

On Fri, Apr 19, 2013 at 1:58 AM, Evan Cheng <evan.cheng at apple.com> wrote:
>
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tail-call-nested-struct.patch
Type: application/octet-stream
Size: 11911 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130419/60609505/attachment.obj>