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

[Evan Cheng]

Ok.

Evan

On Apr 24, 2013, at 6:40 PM, Stephen Lin <swlin at post.harvard.edu> wrote:

> If it's ok with you, I'm going to withdraw this patch. I haven't
> managed to break it with lots of testing, but I agree it's non-obvious
> whether it works 100% correctly, so probably isn't worth the risk
> exposure given that there's no need for this extension.
> 
> If it is ever needed, I think it ought to be rewritten to be clearer
> and/or augmented with a lot more state being passed around and liberal
> assertions for sanity checks. However, since there doesn't seem to be
> a valid use case yet, I think there's no point slowing things down
> with that stuff now.
> 
> -Stephen
> 
> On Tue, Apr 23, 2013 at 1:47 PM, Stephen Lin <swlin at post.harvard.edu> wrote:
>> 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