<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 18, 2013, at 7:05 PM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Mar 18, 2013, at 6:28 PM, Argyrios Kyrtzidis <<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>> wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Mar 17, 2013, at 4:51 PM, John McCall <<a href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>> wrote:<br><div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">On Mar 16, 2013, at 10:14 AM, Argyrios Kyrtzidis <<a href="mailto:kyrtzidis@apple.com">kyrtzidis@apple.com</a>> wrote:<br><blockquote type="cite">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.<br>For example:<br><br>int baz(int x) {<br>switch (x) {<br> case 1: return 10;<br> case 2: return 20;<br>}<br>// implicit unreachable is inserted<br>}<br><br>int baz2(int x) {<br>switch (x) {<br> case 1: return 10;<br> case 2: return 20;<br>}<br>foo();<br>// no unreachable<br>}<br><br>As a consequence, functions that have no returns, will not get the implicit unreachable:<br><br>int baz2(int x) {<br>foo();<br>// no unreachable<br>}<br><br><br>I believe this allows taking advantage of the optimization opportunities that the implicit unreachable intended, in a safer manner.<br></blockquote><br>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.</div></blockquote><div><br></div><div>Could you give some examples ?</div></div></div></blockquote><div><br></div>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."</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Well, it would be impossible to be _more_ disaster than what we currently have, but this is another topic.</div><div>If you don't think checking the IR is safe enough, your point is well taken.</div><div><br></div><div>Thanks for reviewing!</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>John.</div></div></blockquote></div><br></body></html>