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

[Stephen Lin]

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