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

[Evan Cheng]

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