[PATCH] Allow tail call optimization through struct reordering/regrouping

[Stephen Lin]

OK, will do.

On Tue, Apr 23, 2013 at 1:33 PM, Evan Cheng <evan.cheng at apple.com> wrote:
> I see the value of the series of patches but I'm a bit worried about the complexity of the code. It's starting to be hard to reason about it. Do you think you can add a bit more comments to describe the function?
>
> Thanks,
>
> Evan
>
> On Apr 23, 2013, at 10:00 AM, Stephen Lin <swlin at post.harvard.edu> wrote:
>
>> Not a huge priority, but anyone able to take a look at this? I rebased
>> and updated it slightly.
>>
>> The summary is that this patch allows tail call optimization to see
>> through reordering and regrouping of struct elements, as long as the
>> order and grouping is reestablished before the return.
>>
>> -Stephen
>>
>> ---------- Forwarded message ----------
>> From: Stephen Lin <swlin at post.harvard.edu>
>> Date: Mon, Apr 22, 2013 at 11:52 AM
>> Subject: Re: [PATCH] Allow tail call optimization through
>> multiple/nested struct extractions/insertions
>> To: "llvm-commits at cs.uiuc.edu" <llvm-commits at cs.uiuc.edu>
>> Cc: Evan Cheng <evan.cheng at apple.com>
>>
>>
>> On Sat, Apr 20, 2013 at 2:02 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>>> Hmm, in retrospect, this was probably not really worth it, but I
>>> extended this to handle reordering and regrouping of struct elements
>>> (as long as the original order and grouping is reestablished before
>>> the call).
>>>
>>> I know it doesn't seem all that likely to be useful (I'm guessing some
>>> functional code with record types *might* be able to take advantage of
>>> it in some corner cases): I just found the limitation initially when
>>> making a new test and thought it would be very quick fix.
>>>
>>> It ended up being a bit more subtle, actually; but the work is done
>>> now and there's no apparent downside, so I figured I might as well
>>> submit it for review. Also, since it was more subtle than I expected,
>>> I added more plausible false positive cases involving combinations of
>>> nesting, grouping, and undefined values, just to be as certain as
>>> possible it's doing the right thing. If there's any more cases anyone
>>> can think of to add to be safe, please let me know.
>>>
>>> Any comment or suggestion is appreciated. Also, I'm sure there's some
>>> degenerate cases this doesn't handle fully, but this seems like the
>>> cleanest way of handling my originally planned test and other similar
>>> cases without carrying excessive amounts of state around.
>>>
>>> -Stephen
>>>
>>
>> I added another test, to be safe.
>> -Stephen
>> <tail-call-reorder-struct.patch>_______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits