[PATCH] [codegen] Don't emit implicit unreachable at the end of a non-empty block

[Argyrios Kyrtzidis]

On Mar 18, 2013, at 7:05 PM, John McCall <rjmccall at apple.com> wrote:

> On Mar 18, 2013, at 6:28 PM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>> On Mar 17, 2013, at 4:51 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Mar 16, 2013, at 10:14 AM, Argyrios Kyrtzidis <kyrtzidis at apple.com> wrote:
>>>> The attached patch adds a check so that, if we flow off the end of a value-returning function, the implicit unreachable will only be emitted if the returning block is empty.
>>>> For example:
>>>> 
>>>> int baz(int x) {
>>>> switch (x) {
>>>>   case 1: return 10;
>>>>   case 2: return 20;
>>>> }
>>>> // implicit unreachable is inserted
>>>> }
>>>> 
>>>> int baz2(int x) {
>>>> switch (x) {
>>>>   case 1: return 10;
>>>>   case 2: return 20;
>>>> }
>>>> foo();
>>>> // no unreachable
>>>> }
>>>> 
>>>> As a consequence, functions that have no returns, will not get the implicit unreachable:
>>>> 
>>>> int baz2(int x) {
>>>> foo();
>>>> // no unreachable
>>>> }
>>>> 
>>>> 
>>>> I believe this allows taking advantage of the optimization opportunities that the implicit unreachable intended, in a safer manner.
>>> 
>>> Hmm.  There's a pretty large spectrum of ways in which something could end up with a non-empty return block while still conceptually falling off the end in a way we'd like to optimize.
>> 
>> Could you give some examples ?
> 
> Mostly, anything that needs a cleanup.  You could work around this by checking before we pop out of top-level cleanups, though.  On the other hand, there are a lot of ways that you can end up with an empty IR block at the end of a function that have nothing to do with whatever semantic condition you're trying to capture.  I really wouldn't want to explain some of these differences:  "The final line in your function had a conditional cleanup in it, and that branch left us with an empty block, so we decided the end was unreachable."
> 
> If you want to avoid making a CFG or computing -Wreturn-type, you should make this heuristically based on the final statement in the function, possibly recursively.  Come up with some straightforward syntactic rule.  But, having thought about it, using IR structure would be a disaster.

Well, it would be impossible to be _more_ disaster than what we currently have, but this is another topic.
If you don't think checking the IR is safe enough, your point is well taken.

Thanks for reviewing!

> 
> John.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130318/5d6d9d3d/attachment.html>