On Mar 18, 2013, at 6:28 PM, Argyrios Kyrtzidis <[email protected]> wrote: > On Mar 17, 2013, at 4:51 PM, John McCall <[email protected]> wrote: >> On Mar 16, 2013, at 10:14 AM, Argyrios Kyrtzidis <[email protected]> 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. John.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
